Strict-HTML スレッド 3.2 (W2C Recommendation)
1 ：Name_Not_Found：
Strict な HTML(*) について語るスレッド Version 3.2
W3C 信者もそうじゃない人も投稿歓迎。
* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
XHTML 1.1, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。
■過去ログ
1.0 http://pc.2ch.net/hp/kako/992/992708594.html
2.0 http://pc.2ch.net/test/read.cgi/hp/1008380243/
3.0 http://pc.2ch.net/test/read.cgi/hp/1013818251/
■関連スレ
/* CSS、スタイルシート質問スレッド【6】 */ http://pc.2ch.net/test/read.cgi/hp/1011358982/l50
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
W3C信者と感じる瞬間 http://mentai.2ch.net/hp/kako/990/990175066.html
W3C信者の方に質問 http://mentai.2ch.net/hp/kako/977/977621932.html
■勧告等
HTML 4.01 http://www.w3.org/TR/html401/
XHTML 1.0 http://www.w3.org/TR/xhtml1/
XHTML Basic http://www.w3.org/TR/xhtml-basic/
XHTML 1.1 http://www.w3.org/TR/xhtml11/
ISO/IEC 15445 (ISO-HTML) http://woodworm.cs.uml.edu/~rprice/15445/15445.html
JIS X 4156 (JIS-HTML) http://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳など http://www.doraneko.org/webauth/
■その他
W3C http://www.w3.org/
Another HTML-lint http://openlab.ring.gr.jp/k16/htmllint/htmllint.html
W3C HTML Validation Service http://validator.w3.org/
ごく簡単なHTMLの説明 http://kanzaki.com/docs/htminfo.html
W3C 信者もそうじゃない人も投稿歓迎。
* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
XHTML 1.1, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。
■過去ログ
1.0 http://pc.2ch.net/hp/kako/992/992708594.html
2.0 http://pc.2ch.net/test/read.cgi/hp/1008380243/
3.0 http://pc.2ch.net/test/read.cgi/hp/1013818251/
■関連スレ
/* CSS、スタイルシート質問スレッド【6】 */ http://pc.2ch.net/test/read.cgi/hp/1011358982/l50
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
W3C信者と感じる瞬間 http://mentai.2ch.net/hp/kako/990/990175066.html
W3C信者の方に質問 http://mentai.2ch.net/hp/kako/977/977621932.html
■勧告等
HTML 4.01 http://www.w3.org/TR/html401/
XHTML 1.0 http://www.w3.org/TR/xhtml1/
XHTML Basic http://www.w3.org/TR/xhtml-basic/
XHTML 1.1 http://www.w3.org/TR/xhtml11/
ISO/IEC 15445 (ISO-HTML) http://woodworm.cs.uml.edu/~rprice/15445/15445.html
JIS X 4156 (JIS-HTML) http://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳など http://www.doraneko.org/webauth/
■その他
W3C http://www.w3.org/
Another HTML-lint http://openlab.ring.gr.jp/k16/htmllint/htmllint.html
W3C HTML Validation Service http://validator.w3.org/
ごく簡単なHTMLの説明 http://kanzaki.com/docs/htminfo.html
|
|
|
2 ：Name_Not_Found：02/04/14 02:54 ID:7ksGRhA3
2
3 ：自動3ゲットシステム：02/04/14 02:57 ID:mQlc450p
自動3ゲットシステム
4 ：Name_Not_Found：02/04/14 03:02 ID:jlaBYmNj
スレ建てお疲れ様でした。
CSS質問スレッドは、新スレ
/* CSS、スタイルシート質問スレッド【7】 */
http://pc.2ch.net/test/read.cgi/hp/1015474859/
にすべきだった様な気もするけれど。
しかし、3.2かあ。途中でdat落ちしそうで怖い。
CSS質問スレッドは、新スレ
/* CSS、スタイルシート質問スレッド【7】 */
http://pc.2ch.net/test/read.cgi/hp/1015474859/
にすべきだった様な気もするけれど。
しかし、3.2かあ。途中でdat落ちしそうで怖い。
5 ：Name_Not_Found：02/04/14 03:30 ID:m6DHB9Fo
5...
6 ：Name_Not_Found：02/04/14 05:35 ID:8fdBM9oY
スレタイトルが strict でないってのはいかがなものか。
7 ：Name_Not_Found：02/04/14 08:51 ID:SHRI28bK
せめてVer.5.01とかの方が…
8 ：Name_Not_Found：02/04/14 08:58 ID:j10wVMVa
スレタイトルの 3.2 は洒落がきいてていいと思うけどナ。
ただまぁ、そこまでやるなら 2 の次は 2.x だったな。
ただまぁ、そこまでやるなら 2 の次は 2.x だったな。
9 ：Name_Not_Found：02/04/14 10:12 ID:SHRI28bK
<?xml version="1.0" encoding="Unicode"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Unicode">
<meta name="keywords" xml:lang="en"
<meta name="keywords" xml:lang="ja"
<meta name="description" xml:lang="en"
<meta name="description" xml:lang="ja"
このようにに作ってるんですが、<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
のlang="en"で良いのか。deやjaが適切なのかわかりません。
Unicodeの特徴である1枚のテキストに複数言語をは実践できましたがここだけが心残りで…
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Unicode">
<meta name="keywords" xml:lang="en"
<meta name="keywords" xml:lang="ja"
<meta name="description" xml:lang="en"
<meta name="description" xml:lang="ja"
このようにに作ってるんですが、<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
のlang="en"で良いのか。deやjaが適切なのかわかりません。
Unicodeの特徴である1枚のテキストに複数言語をは実践できましたがここだけが心残りで…
10 ：Name_Not_Found：02/04/14 10:14 ID:o39f+m+u
誰か【詳解HTML&XHTML&CSS辞典】買った人居る？
辞典系、分かりやすくてついつい買ってしまう…。
辞典系、分かりやすくてついつい買ってしまう…。
<meta name="keywords" xml:lang="en"
<meta name="keywords" xml:lang="ja"
<meta name="keywords" xml:lang="de"
<meta name="description" xml:lang="en"
<meta name="description" xml:lang="ja"
<meta name="description" xml:lang="de"
日本語・英語・ドイツ語のページです。トップ以外は各言語別に作ってあります。
英語はus-ascii、日本語はiso-2022-jp、ドイツ語はeuc-de
<meta name="keywords" xml:lang="ja"
<meta name="keywords" xml:lang="de"
<meta name="description" xml:lang="en"
<meta name="description" xml:lang="ja"
<meta name="description" xml:lang="de"
日本語・英語・ドイツ語のページです。トップ以外は各言語別に作ってあります。
英語はus-ascii、日本語はiso-2022-jp、ドイツ語はeuc-de
13 ：Name_Not_Found：02/04/14 10:24 ID:o39f+m+u
間隔→感覚です。ｽﾏｿ
16 ：Name_Not_Found：02/04/14 12:30 ID:t93Qo3oK
Unicodeエンコーディングはよくない。UTF-8を使うべき。(XML宣言までに非ascii文字が含まれてしまう)
>ttp://www.w3.org/TR/REC-xml#sec-lang-tag
xml:langの使い方は適切です。
>ttp://www.w3.org/TR/REC-xml#sec-lang-tag
xml:langの使い方は適切です。
17 ：Name_Not_Found：02/04/14 14:46 ID:uYhdztey
素人質問でｽﾏｿ。
タイトル画像とかってどの要素を使うのが妥当なんですかね？
今は<h1>とか使ってるんですが。それとも文字無しで画像だけなら
<span>使う方が良いのでしょうか。ご指導おながいしまそ。
タイトル画像とかってどの要素を使うのが妥当なんですかね？
今は<h1>とか使ってるんですが。それとも文字無しで画像だけなら
<span>使う方が良いのでしょうか。ご指導おながいしまそ。
19 ：Name_Not_Found：02/04/14 14:56 ID:uYhdztey
20 ：Name_Not_Found：02/04/14 14:58 ID:2LVE1GEG
>17
タイトルが画像なら、そのタイトル画像のalt属性に
適切なテキストを書いておけばいいだけだと思いますが。
タイトルが画像なら、そのタイトル画像のalt属性に
適切なテキストを書いておけばいいだけだと思いますが。
>>20
音声ブラウザは無視？
一番良いのは<h1>にタイトル書いてCSSで無視
そいで<img>で画像タイトルもちろんaitもつける
こんだけでわざわざやり直すかあ？とは思う。Transtionalに行ったほうが良いんじゃないか？>19
音声ブラウザは無視？
一番良いのは<h1>にタイトル書いてCSSで無視
そいで<img>で画像タイトルもちろんaitもつける
こんだけでわざわざやり直すかあ？とは思う。Transtionalに行ったほうが良いんじゃないか？>19
22 ：Name_Not_Found：02/04/14 15:10 ID:uYhdztey
>>20
あ、そんなんで良いんですか？（・∀・；）
だったら大丈夫だ。画像には全部alt属性付けてます。alt="画像"とかじゃ無いっすよ(ｗ
あとどっかで以前target_blank以前の話題ありましたよね？
やっぱりjava scriptで飛ばすべきなんですか？
結果がどうなってたのか見れなかったもんで。質問ばっかでｽﾏｿ。
あ、そんなんで良いんですか？（・∀・；）
だったら大丈夫だ。画像には全部alt属性付けてます。alt="画像"とかじゃ無いっすよ(ｗ
あとどっかで以前target_blank以前の話題ありましたよね？
やっぱりjava scriptで飛ばすべきなんですか？
結果がどうなってたのか見れなかったもんで。質問ばっかでｽﾏｿ。
23 ：Name_Not_Found：02/04/14 15:11 ID:xRlWTJAm
具体的には「○○のウェブサイト」がサイト名で、画像が titlelogo.jpeg なら
<h1><img src="titlelogo.jpeg" alt="○○のウェブサイト"></h1>
でＯＫ。
逆に>>18 の方法だと、画像は表示するがCSS非対応のUAだと
文字と画像が両方とも表示さて（場合によって）変な事になる。
<h1><img src="titlelogo.jpeg" alt="○○のウェブサイト"></h1>
でＯＫ。
逆に>>18 の方法だと、画像は表示するがCSS非対応のUAだと
文字と画像が両方とも表示さて（場合によって）変な事になる。
h1
{
display:none
}
これで良いんじゃない？
{
display:none
}
これで良いんじゃない？
>>23
>画像は表示するがCSS非対応のUAだと文字と画像が両方とも表示
たしかに表示されるね。でも、<h1>はLynxとかでもちゃんと見出しとして表示される。altだと小さい文字が出るだけだったり。
>画像は表示するがCSS非対応のUAだと文字と画像が両方とも表示
たしかに表示されるね。でも、<h1>はLynxとかでもちゃんと見出しとして表示される。altだと小さい文字が出るだけだったり。
26 ：Name_Not_Found：02/04/14 15:22 ID:WmZ52TKe
27 ：Name_Not_Found：02/04/14 15:24 ID:uYhdztey
>>23
あ、今がそんな感じです。レスさんくすです。
>>21=24
いやぁ、今Transitionalなんですが、やはり個人のサイトとは言え
将来的にstrict必須かと思いましてね。
h1
{
display : none ;
}
これやっちゃうと23さんが言ってるように変な事にならないですかね？
それとも画像は<h1>で囲まずに他の要素で囲むって事ですか？
房な質問だったら出なおしてきます。
あ、今がそんな感じです。レスさんくすです。
>>21=24
いやぁ、今Transitionalなんですが、やはり個人のサイトとは言え
将来的にstrict必須かと思いましてね。
h1
{
display : none ;
}
これやっちゃうと23さんが言ってるように変な事にならないですかね？
それとも画像は<h1>で囲まずに他の要素で囲むって事ですか？
房な質問だったら出なおしてきます。
29 ：Name_Not_Found：02/04/14 15:25 ID:uYhdztey
被った鬱氏。。。
>>25
ユーザスタイルシートを適用している場合は？ 普通 h1 は display:block に
なると思われるが？（ユーザが真っ当なスタイルシートを適用してぶっ壊れる
HTML を組むのはよろしくないのでは？ という事）
あと、ｈ１に文字を入れたとして、タイトル画像は何でマークアップするの？
ｈ１以外の何者でもないはずなんだが、どうか？
あと、alt を読まない音声ブラウザがあるとしたら、それは音声ブラウザ側の
落ち度。画像表示出来ないくせに alt を表示できない文字ブラウザくらいヘボ。
ユーザスタイルシートを適用している場合は？ 普通 h1 は display:block に
なると思われるが？（ユーザが真っ当なスタイルシートを適用してぶっ壊れる
HTML を組むのはよろしくないのでは？ という事）
あと、ｈ１に文字を入れたとして、タイトル画像は何でマークアップするの？
ｈ１以外の何者でもないはずなんだが、どうか？
あと、alt を読まない音声ブラウザがあるとしたら、それは音声ブラウザ側の
落ち度。画像表示出来ないくせに alt を表示できない文字ブラウザくらいヘボ。
>>27
私が言ってるのは
<h1 id="title" title="title" lang="en" dir="ltr">title</h1>
<hr>
<img />
って感じで<img>の部分で画像を表示
で、CSS
h1
{
display : none ;
}
私が言ってるのは
<h1 id="title" title="title" lang="en" dir="ltr">title</h1>
<hr>
<img />
って感じで<img>の部分で画像を表示
で、CSS
h1
{
display : none ;
}
32 ：Name_Not_Found：02/04/14 16:03 ID:7fQnsYSe
altの無いimgなんて使うな
>21
音声ブラウザは無視って……。そもそも画像による表現ができない環境のための
alt属性なのであって、それがテキストブラウザだろうが音声ブラウザだろうが
alt属性さえきちんと記述してあれば何らかの代替表現をするはず。
23に書いてあるような記述で十分だと思いますが。
あと、31で何のブロック要素にも包まずにimg要素が出現している方が
Strictじゃないと思う。
音声ブラウザは無視って……。そもそも画像による表現ができない環境のための
alt属性なのであって、それがテキストブラウザだろうが音声ブラウザだろうが
alt属性さえきちんと記述してあれば何らかの代替表現をするはず。
23に書いてあるような記述で十分だと思いますが。
あと、31で何のブロック要素にも包まずにimg要素が出現している方が
Strictじゃないと思う。
34 ：Name_Not_Found：02/04/14 16:06 ID:8wcmbzah
質問です。
短編小説を書いたんですが、どうマークアップしてよいか悩んでいます。
話の中に段落と呼べるような区切りはないのですが、読むリズムをつけるために所々で空行を入れています。
そういう場合の空行はどの要素を使ったらいいんでしょう？
<P>か<BR>か、それとも<PRE>で整形済みテキストとして扱うべきか。
よろしくお願いします。
短編小説を書いたんですが、どうマークアップしてよいか悩んでいます。
話の中に段落と呼べるような区切りはないのですが、読むリズムをつけるために所々で空行を入れています。
そういう場合の空行はどの要素を使ったらいいんでしょう？
<P>か<BR>か、それとも<PRE>で整形済みテキストとして扱うべきか。
よろしくお願いします。
<hr>は駄目かな。
36 ：Name_Not_Found：02/04/14 16:27 ID:k1v5cI8r
>>34
複数ファイルに分けてリンクにするとか。
普通に考えれば <br> にしかならないんだけど、小説って <hx> 以外
殆どタグ付けする必要なさそうだから、いっそ <pre> で囲ったほうが
速い気がする。
複数ファイルに分けてリンクにするとか。
普通に考えれば <br> にしかならないんだけど、小説って <hx> 以外
殆どタグ付けする必要なさそうだから、いっそ <pre> で囲ったほうが
速い気がする。
37 ：1：02/04/14 16:29 ID:/h+pZ9Bg
>>34
hrで水平線を入れるのが一般的では。
物理的要素のhrを使うのがイヤだという場合は、
節ごとにdivで囲んで、CSSで
div {
margin-bottom : 1em
}
とか指定してやるとか。
後者だと、CSS切ってるとまったく間隔が空かないのが難だけど。
あと、節ごとに適切な見出しを入れてやって、h2～h6でマーク付けするのも
手だと思う。
hrで水平線を入れるのが一般的では。
物理的要素のhrを使うのがイヤだという場合は、
節ごとにdivで囲んで、CSSで
div {
margin-bottom : 1em
}
とか指定してやるとか。
後者だと、CSS切ってるとまったく間隔が空かないのが難だけど。
あと、節ごとに適切な見出しを入れてやって、h2～h6でマーク付けするのも
手だと思う。
38 ：茶文字 ◆xELvisFU ：02/04/14 16:52 ID:qbYNIyQj
>>33に概ね同意。
imgをh1の外に出した場合、肝心のimgはどの要素に入れるべきなのかという
疑問も生じる。
>>37
div{
margin-bottom : 1em ;
}
hr{
display : none ;
}
これでCSSオフ環境にも対応できるのでは？
imgをh1の外に出した場合、肝心のimgはどの要素に入れるべきなのかという
疑問も生じる。
>>37
div{
margin-bottom : 1em ;
}
hr{
display : none ;
}
これでCSSオフ環境にも対応できるのでは？
みなさんアドバイスありがとうございました。
参考にして、何パターンか試して検証してみますね。
参考にして、何パターンか試して検証してみますね。
40 ：Name_Not_Found：02/04/14 18:47 ID:8fdBM9oY
>>10-15
HTML & XHTML & CSS は良書。
しかし HTML & CSS & Javascript (だっけ)は HTML 部分がへぼい。
こちらはちょっと strict とは言い難い。
なので HTML のためには前者を推奨。
>>38 後半
hr はどう足掻いても物理要素。
strict DTD に含まれるとは言え、big/small や i/tt など同様
このスレ的には宜しくないと思うが如何。
HTML & XHTML & CSS は良書。
しかし HTML & CSS & Javascript (だっけ)は HTML 部分がへぼい。
こちらはちょっと strict とは言い難い。
なので HTML のためには前者を推奨。
>>38 後半
hr はどう足掻いても物理要素。
strict DTD に含まれるとは言え、big/small や i/tt など同様
このスレ的には宜しくないと思うが如何。
41 ：Name_Not_Found：02/04/14 19:14 ID:t93Qo3oK
>>28
WinNT系メモ帳で保存したutf-8ではXML宣言の前に非ascii文字が含まれてしまうので意味がない気がする。
>>40
自分も昔はbr->インラインな区切り、hr->ブロックな区切りだと思い込んでいたがW3Cの見解ではhrは物理要素らしいんだよな。この辺がややこしい。
h1にborder-topあるいはborder-bottomスタイルつけるのがもっとも適切だと思う。(divは汎用属性なのであまりスタイル付けすべきではないのでは・・・)
WinNT系メモ帳で保存したutf-8ではXML宣言の前に非ascii文字が含まれてしまうので意味がない気がする。
>>40
自分も昔はbr->インラインな区切り、hr->ブロックな区切りだと思い込んでいたがW3Cの見解ではhrは物理要素らしいんだよな。この辺がややこしい。
h1にborder-topあるいはborder-bottomスタイルつけるのがもっとも適切だと思う。(divは汎用属性なのであまりスタイル付けすべきではないのでは・・・)
>>41の補足
>WinNT系メモ帳で保存したutf-8ではXML宣言の前に非ascii文字が含まれてしまうので意味がない気がする。
空の文書をメモ帳でutf-8保存してみるとわかると思うけど、冒頭にascii領域にない識別コードが入って3バイトになってしまう(本来なら0バイトになるべきかと)。
秀丸で保存するとこの3バイト含まれないので自分は普段これを利用している。
>WinNT系メモ帳で保存したutf-8ではXML宣言の前に非ascii文字が含まれてしまうので意味がない気がする。
空の文書をメモ帳でutf-8保存してみるとわかると思うけど、冒頭にascii領域にない識別コードが入って3バイトになってしまう(本来なら0バイトになるべきかと)。
秀丸で保存するとこの3バイト含まれないので自分は普段これを利用している。
43 ：茶文字 ◆xELvisFU ：02/04/14 19:34 ID:ji7PAzmD
>>40
ドキュメントの作り手の心情になって考えてみたつもりだったんだけど、
たとえば各段落に小見出しを設けるのは本意ではないこともあると思うのね。
小説の部分ごとに小見出しなんて入れてたら煩雑な作業になるし、
実際煩雑そうに見えると思うんだ。
今のところ大段落と小段落を区別するマークアップは難しいと思うので、
たとえば(ソースではなく)本文をWindowsやMacintoshでテキストエディタに
コピペしたときに「---------」で代貸されるhrは捨てたもんじゃないと思うわけ。
確かにhrもbrも物理「的」要素なので、私自身は積極的には使わないけれど。
# そうなるとpreの出番？しかし何か違和感を感じるんだなぁ。
ドキュメントの作り手の心情になって考えてみたつもりだったんだけど、
たとえば各段落に小見出しを設けるのは本意ではないこともあると思うのね。
小説の部分ごとに小見出しなんて入れてたら煩雑な作業になるし、
実際煩雑そうに見えると思うんだ。
今のところ大段落と小段落を区別するマークアップは難しいと思うので、
たとえば(ソースではなく)本文をWindowsやMacintoshでテキストエディタに
コピペしたときに「---------」で代貸されるhrは捨てたもんじゃないと思うわけ。
確かにhrもbrも物理「的」要素なので、私自身は積極的には使わないけれど。
# そうなるとpreの出番？しかし何か違和感を感じるんだなぁ。
>>43
brは物理的要素ではありません。"区切り"という意味の論理的要素です。
hrは見出し要素のborderで代用できるので不要かと。
>コピペしたときに「---------」で代貸されるhrは捨てたもんじゃないと思うわけ。
それはブラウザの実装であってW3Cの仕様ではありません。その期待は無意味です。
brは物理的要素ではありません。"区切り"という意味の論理的要素です。
hrは見出し要素のborderで代用できるので不要かと。
>コピペしたときに「---------」で代貸されるhrは捨てたもんじゃないと思うわけ。
それはブラウザの実装であってW3Cの仕様ではありません。その期待は無意味です。
>>44の補足
>hrは見出し要素のborderで代用できるので不要かと。
1. hr間またはhrと文書終端間の内容に対して見出しを立てることができるなら、立てた見出し要素にborder-topを指定すればよい。
2. hr間またはhrと文書終端間の内容が見出しを立てるまでもない内容ならば空の見出し要素を記述し、border-topを指定すればよい。
例:<h1 />(*)
名前をつけるまでもないセクションという意味でいわば"匿名セクション"という感じにすればよい。
もちろん1.が推奨されるが、いわばalt属性を立てるまでもないimg要素のように、匿名セクションも許容されると思う。見出し要素の階層構造も保てる。
* <h1></h1>とすべきだが空内容だということを強調するために<h1 />とした。
>hrは見出し要素のborderで代用できるので不要かと。
1. hr間またはhrと文書終端間の内容に対して見出しを立てることができるなら、立てた見出し要素にborder-topを指定すればよい。
2. hr間またはhrと文書終端間の内容が見出しを立てるまでもない内容ならば空の見出し要素を記述し、border-topを指定すればよい。
例:<h1 />(*)
名前をつけるまでもないセクションという意味でいわば"匿名セクション"という感じにすればよい。
もちろん1.が推奨されるが、いわばalt属性を立てるまでもないimg要素のように、匿名セクションも許容されると思う。見出し要素の階層構造も保てる。
* <h1></h1>とすべきだが空内容だということを強調するために<h1 />とした。
46 ：Name_Not_Found：02/04/14 20:30 ID:j3p4WEiZ
>>44
br は forced line break(強制改行) で物理的要素だが？
br は forced line break(強制改行) で物理的要素だが？
47 ：Name_Not_Found：02/04/14 20:36 ID:k1v5cI8r
48 ：茶文字 ◆xELvisFU ：02/04/14 20:48 ID:ji7PAzmD
>>44後半は同意。
だから私も積極的に使わないんであって。
が、brが区切りを意味するならhrだって区切りを意味するのでは？
由来はhirizontal ruleだけど、それを言い出せば>>46の指摘もあるわけで。
で、ここから<h1 />について。
微妙だね。うまく言えないが何か違和感が。
本文が先にあってマークアップがついてくるという前提にたつ場合、
h1によってマークアップされた本文はどの部分？
# 紙媒体の原稿があると仮定して、大段落間の空白をマークアップした
# というのは何か違う気がする。
↑だからこそスタイルシートの存在意義があるのであって、
スタイルシート無効の表現力を補うために<h1 />を用いるなら、
hrの方がまだStrict(妙な言い回しだ；)な気がする。
だから私も積極的に使わないんであって。
が、brが区切りを意味するならhrだって区切りを意味するのでは？
由来はhirizontal ruleだけど、それを言い出せば>>46の指摘もあるわけで。
で、ここから<h1 />について。
微妙だね。うまく言えないが何か違和感が。
本文が先にあってマークアップがついてくるという前提にたつ場合、
h1によってマークアップされた本文はどの部分？
# 紙媒体の原稿があると仮定して、大段落間の空白をマークアップした
# というのは何か違う気がする。
↑だからこそスタイルシートの存在意義があるのであって、
スタイルシート無効の表現力を補うために<h1 />を用いるなら、
hrの方がまだStrict(妙な言い回しだ；)な気がする。
49 ：Name_Not_Found：02/04/14 21:00 ID:k1v5cI8r
現在strict+CSSで作っている人間の思考回路は
CSS非対応UAでは、表示結果はUAのデフォルトスタイルシートに依存します
ではなく
CSS非対応UAでは、こちらの意図しない見栄えになります。そこんとこよろしく
だと思うが如何か？
CSS非対応UAでは、表示結果はUAのデフォルトスタイルシートに依存します
ではなく
CSS非対応UAでは、こちらの意図しない見栄えになります。そこんとこよろしく
だと思うが如何か？
50 ：Name_Not_Found：02/04/14 21:08 ID:rhoestWY
51 ：Name_Not_Found：02/04/14 21:13 ID:Y9KRORUH
>>46
そうかもしれません。でも、br要素はすべてのブラウザで(音声ブラウザでも)解釈されなければならない要素のセットであるXHTML Host Modulesに入っています。
つまり、強制改行するだけでなく、間を取る、などのように拡大解釈してよい、もっといえば、区切りという論理的な意味を持っていると考えることもできるのではないでしょうか?
そうかもしれません。でも、br要素はすべてのブラウザで(音声ブラウザでも)解釈されなければならない要素のセットであるXHTML Host Modulesに入っています。
つまり、強制改行するだけでなく、間を取る、などのように拡大解釈してよい、もっといえば、区切りという論理的な意味を持っていると考えることもできるのではないでしょうか?
53 ：Name_Not_Found：02/04/14 22:50 ID:8fdBM9oY
>>52
インラインの区切りは span で足りると思うけど。
span でなく敢えて br でマークする意味は
「見栄え上の改行を入れる」以外にはないのでは?
そしてそれは本来スタイルシートの処理すべき範疇なのでは?
インラインの区切りは span で足りると思うけど。
span でなく敢えて br でマークする意味は
「見栄え上の改行を入れる」以外にはないのでは?
そしてそれは本来スタイルシートの処理すべき範疇なのでは?
54 ：Name_Not_Found：02/04/14 23:48 ID:n+eEqOXh
結局は少なからず妥協しなければ、やっていけない現状なんだね。(;´Д`)
55 ：Name_Not_Found：02/04/15 00:05 ID:YdZzKfIG
>>49
> そこんとこよろしく
むしろ CSS 部分対応/異常対応に対して、のような気がしたり。
尤も完全対応ブラウザなんぞまだ無いんだが。
意図しない見栄えといえば、よく思うんだけど
CSS でポジショニングとか使いまくっている人の
ユーザースタイルシート使用者に対するスタンスってどんな感じなんだろう。
!important のユーザースタイルって不十分な CSS 実装と似ている気がするんだが。
CSS の一部分だけ上書きしておいて読めないと言うのは勘弁してくれとか
やっぱ思うんだろうか？
ユーザースタイルにも問題の出やすいものと出にくいものがあると思うので
その辺の Tips みたいなものを解説サイトでレクチャーできると良いかもと思う。
ｶﾅｰﾘスレ違い気味でｽﾏｿ。
> そこんとこよろしく
むしろ CSS 部分対応/異常対応に対して、のような気がしたり。
尤も完全対応ブラウザなんぞまだ無いんだが。
意図しない見栄えといえば、よく思うんだけど
CSS でポジショニングとか使いまくっている人の
ユーザースタイルシート使用者に対するスタンスってどんな感じなんだろう。
!important のユーザースタイルって不十分な CSS 実装と似ている気がするんだが。
CSS の一部分だけ上書きしておいて読めないと言うのは勘弁してくれとか
やっぱ思うんだろうか？
ユーザースタイルにも問題の出やすいものと出にくいものがあると思うので
その辺の Tips みたいなものを解説サイトでレクチャーできると良いかもと思う。
ｶﾅｰﾘスレ違い気味でｽﾏｿ。
56 ：Name_Not_Found：02/04/15 00:41 ID:f1Ip5w2R
>>45
>2. hr間またはhrと文書終端間の内容が見出しを立てるまでもない内容ならば空の見出し要素を記述し、border-topを指定すればよい。
>例:<h1 />(*)
意味段落ごとに <div class="section"> とでもして囲めばよいかと。
表示する時、空間や線が欲しければ CSS の設定をお好みで。
少なくとも、見出しを立てるまでもないのに、見出し要素を tag だけ存在させるよりは
ましなマークアップかと。
>>52
>つまり、強制改行するだけでなく、間を取る、などのように拡大解釈してよい、もっといえば、区切りという論理的な意味を持っていると考えることもできるのではないでしょうか?
つまり、big も音声ブラウザは大きな声で読むべきで、強調のように拡大解釈してもよいと？
「拡大解釈」している段階で、本来の解釈と違う訳であって、strict スレ的にNGかと。
>>55
>CSS の一部分だけ上書きしておいて読めないと言うのは勘弁してくれとか
>やっぱ思うんだろうか？
思う。ので俺は一部ではなく、全部の要素の CSS 設定を上書きしている。
ので、HTML がヘボでなければ困る事はない。
>2. hr間またはhrと文書終端間の内容が見出しを立てるまでもない内容ならば空の見出し要素を記述し、border-topを指定すればよい。
>例:<h1 />(*)
意味段落ごとに <div class="section"> とでもして囲めばよいかと。
表示する時、空間や線が欲しければ CSS の設定をお好みで。
少なくとも、見出しを立てるまでもないのに、見出し要素を tag だけ存在させるよりは
ましなマークアップかと。
>>52
>つまり、強制改行するだけでなく、間を取る、などのように拡大解釈してよい、もっといえば、区切りという論理的な意味を持っていると考えることもできるのではないでしょうか?
つまり、big も音声ブラウザは大きな声で読むべきで、強調のように拡大解釈してもよいと？
「拡大解釈」している段階で、本来の解釈と違う訳であって、strict スレ的にNGかと。
>>55
>CSS の一部分だけ上書きしておいて読めないと言うのは勘弁してくれとか
>やっぱ思うんだろうか？
思う。ので俺は一部ではなく、全部の要素の CSS 設定を上書きしている。
ので、HTML がヘボでなければ困る事はない。
57 ：Name_Not_Found：02/04/15 00:54 ID:fUPJwwwf
>>34がかわいそうになってきた。
小説のマークアップ1つでこれだけ悩まなければならないとは。
某方面にもこういうのが好きな手合いが大量に居るが、
もっとエンドユーザが楽に使える方法は無いのかね。
「制作者側の」ユーザビリティーが低すぎる。
小説のマークアップ1つでこれだけ悩まなければならないとは。
某方面にもこういうのが好きな手合いが大量に居るが、
もっとエンドユーザが楽に使える方法は無いのかね。
「制作者側の」ユーザビリティーが低すぎる。
58 ：Name_Not_Found：02/04/15 01:27 ID:eAd/BnO3
>>57
HTML には「間」をマークアップする、という概念が存在しないので、
仕方なく hr とか br とかで「間」を表現しようとして、それが物理系だのなんだのと、
ややこしくなっているのが原因かと。
strict スレ的には <div class="space" /> 若しくは <span class="speace" />
とでもするしかないと思うが CSS 非対応UAも考慮にいれるなら、
<hr class="space"> もしくは <br class="space"> となるものと思われる。
と言うか、スタイルシートが働かない状態で、表示を制御しようってんだから、
物理要素に頼るしかないのは自明なわけで。
＃この場合、class 名の space は文書構造としての「間」の意。念の為。
HTML には「間」をマークアップする、という概念が存在しないので、
仕方なく hr とか br とかで「間」を表現しようとして、それが物理系だのなんだのと、
ややこしくなっているのが原因かと。
strict スレ的には <div class="space" /> 若しくは <span class="speace" />
とでもするしかないと思うが CSS 非対応UAも考慮にいれるなら、
<hr class="space"> もしくは <br class="space"> となるものと思われる。
と言うか、スタイルシートが働かない状態で、表示を制御しようってんだから、
物理要素に頼るしかないのは自明なわけで。
＃この場合、class 名の space は文書構造としての「間」の意。念の為。
59 ：1：02/04/15 01:40 ID:+91u6ktM
>>57
少なくとも現段階では、
「brやhrは仕様には存在するが、物理要素だから使いたくない」
というのは個人の嗜好のレベルの問題で、
「使うべきではない。使うな」
とまで言う根拠に乏しい（由来がどうであれ、現実には「区切り」として
認識がコンセンサスを得ている）と思うので、
>>34が納得できるのであれば、>>38で示されているdivとhrの併用で
いいんじゃないかと。
少なくとも現段階では、
「brやhrは仕様には存在するが、物理要素だから使いたくない」
というのは個人の嗜好のレベルの問題で、
「使うべきではない。使うな」
とまで言う根拠に乏しい（由来がどうであれ、現実には「区切り」として
認識がコンセンサスを得ている）と思うので、
>>34が納得できるのであれば、>>38で示されているdivとhrの併用で
いいんじゃないかと。
60 ：1：02/04/15 01:44 ID:+91u6ktM
>>58
brを使用する場合、body直下にインライン要素は書けないので、
どのブロック要素でbrをマークするか、という問題も出てくるね。
<div class="pause"><br></div>
とか？
brを使用する場合、body直下にインライン要素は書けないので、
どのブロック要素でbrをマークするか、という問題も出てくるね。
<div class="pause"><br></div>
とか？
61 ：茶文字 ◆xELvisFU ：02/04/15 01:45 ID:7F89iwmG
Strictの意義をどこに求めるかが微妙にずれてきた気がする。
>>58の「スタイルシートが働かない状態で表示を制御しようとするなら
物理要素に頼るしかない」をきっかけに考えてみたんだけど、
Strictってのは「CSSがなくても意図がわかるように構造をマークアップで示す」のであって
「CSSが利かない場合を考慮して物理マークアップもやっておく」というのではない気が。
視点を変えて、ソースから制作者の意図を把握できるようなマークアップをStrictの条件とするなら、
いわゆる「間」の部分を<h1 />などとするのはやはり違うと思うのね。
ソースから直感的に意図を把握しやすいという点ではhrがわかりやすいが、
これは物理的な要素だからｶﾞｲｼｭﾂのようにdivで大段落をまとめるのが
適切ではないかという気がしてきた。
結果的にスタイルシートをOFFったUAは大段落の区切りを表現しないかも知れないが、
今のところStrict的には一番妥当な意見に思えるんだがどうだろう。
>>58の「スタイルシートが働かない状態で表示を制御しようとするなら
物理要素に頼るしかない」をきっかけに考えてみたんだけど、
Strictってのは「CSSがなくても意図がわかるように構造をマークアップで示す」のであって
「CSSが利かない場合を考慮して物理マークアップもやっておく」というのではない気が。
視点を変えて、ソースから制作者の意図を把握できるようなマークアップをStrictの条件とするなら、
いわゆる「間」の部分を<h1 />などとするのはやはり違うと思うのね。
ソースから直感的に意図を把握しやすいという点ではhrがわかりやすいが、
これは物理的な要素だからｶﾞｲｼｭﾂのようにdivで大段落をまとめるのが
適切ではないかという気がしてきた。
結果的にスタイルシートをOFFったUAは大段落の区切りを表現しないかも知れないが、
今のところStrict的には一番妥当な意見に思えるんだがどうだろう。
# IDが気に入ったので調子に乗って
個人的には>>59-60 (1) 氏の意見に同調したいが、
>>58
> HTML には「間」をマークアップする、という概念が存在しないので
所詮元がアルファベット圏で生まれた規格だしな。
# PML(Poem Markup Language)ｷﾎﾞﾝ(w
parserに食わすのに支障無ければ・・・なんてことを言ってしまうと
スレタイから逸脱するので、やっぱここはpre、と
荒唐無稽な提案をしてみるテスト
個人的には>>59-60 (1) 氏の意見に同調したいが、
>>58
> HTML には「間」をマークアップする、という概念が存在しないので
所詮元がアルファベット圏で生まれた規格だしな。
# PML(Poem Markup Language)ｷﾎﾞﾝ(w
parserに食わすのに支障無ければ・・・なんてことを言ってしまうと
スレタイから逸脱するので、やっぱここはpre、と
荒唐無稽な提案をしてみるテスト
63 ：Name_Not_Found：02/04/15 02:22 ID:VmQsOzvM
>>59
> 由来がどうであれ、現実には「区切り」として
> 認識がコンセンサスを得ている
そんなことを言い出したら「font size="7" ≒ strong」だって
認められることになってしまうから駄目だって言ってるんだが。
仕様は仕様通りに使うべき。
>>58 の
> と言うか、スタイルシートが働かない状態で、表示を制御しようってんだから、
> 物理要素に頼るしかないのは自明なわけで。
というのが端的に示していると思うが、その次元での後方互換が本当に必要か?
結局、
> 結果的にスタイルシートをOFFったUAは大段落の区切りを表現しないかも知れないが、
> 今のところStrict的には一番妥当な意見に思えるんだがどうだろう。
ということで、適切な class を指定した div でマークするのが妥当だと思う。
それと、そもそも HTML は小説をマークするための言語ではないから、
そういう表現に難があるのは仕方がない。
理想的には XHTML を使って、適当に要素を拡張するのが好ましい。
> 由来がどうであれ、現実には「区切り」として
> 認識がコンセンサスを得ている
そんなことを言い出したら「font size="7" ≒ strong」だって
認められることになってしまうから駄目だって言ってるんだが。
仕様は仕様通りに使うべき。
>>58 の
> と言うか、スタイルシートが働かない状態で、表示を制御しようってんだから、
> 物理要素に頼るしかないのは自明なわけで。
というのが端的に示していると思うが、その次元での後方互換が本当に必要か?
結局、
> 結果的にスタイルシートをOFFったUAは大段落の区切りを表現しないかも知れないが、
> 今のところStrict的には一番妥当な意見に思えるんだがどうだろう。
ということで、適切な class を指定した div でマークするのが妥当だと思う。
それと、そもそも HTML は小説をマークするための言語ではないから、
そういう表現に難があるのは仕方がない。
理想的には XHTML を使って、適当に要素を拡張するのが好ましい。
64 ：Name_Not_Found：02/04/15 10:24 ID:Uh0bqERo
65 ： ：02/04/15 12:26 ID:YTj0Qqyo
>64
display: none; が有効でない環境のために見出しが書ける（書く内容がある）なら
dispaly: none; する必要がないと思うんだけど．
＃ところで前スレは早くも倉庫行き？
display: none; が有効でない環境のために見出しが書ける（書く内容がある）なら
dispaly: none; する必要がないと思うんだけど．
＃ところで前スレは早くも倉庫行き？
66 ：520：02/04/15 12:47 ID:U0EBNBFh
>>63
> そんなことを言い出したら「font size="7" ≒ strong」だって
> 認められることになってしまうから駄目だって言ってるんだが。
> 仕様は仕様通りに使うべき。
仕様で破棄されてるfontと、仕様に存在するhrではまた違うと思うんですが。
俺も、divで区切ってやるのが一番Strictだと思うけど、その補助的にhrを
使うのは、ギリギリセーフなんじゃないかな。
>>65
論文とか理詰めの文章だったら、適切な見出しをつけた方が絶対親切だし、
文書の再利用性も高まるけど、文学作品の場合は「見出し」つけちゃうと
野暮になっちゃう場合もあるから難しい。
やはりHTMLは文学作品をマークアップするための言語じゃないってことか。
> そんなことを言い出したら「font size="7" ≒ strong」だって
> 認められることになってしまうから駄目だって言ってるんだが。
> 仕様は仕様通りに使うべき。
仕様で破棄されてるfontと、仕様に存在するhrではまた違うと思うんですが。
俺も、divで区切ってやるのが一番Strictだと思うけど、その補助的にhrを
使うのは、ギリギリセーフなんじゃないかな。
>>65
論文とか理詰めの文章だったら、適切な見出しをつけた方が絶対親切だし、
文書の再利用性も高まるけど、文学作品の場合は「見出し」つけちゃうと
野暮になっちゃう場合もあるから難しい。
やはりHTMLは文学作品をマークアップするための言語じゃないってことか。
>>65
適切な見出しがすべての段落で書けなくても
見出しを配置することで文書構造がわかりやすくなるなら
それはそれでStrictとしてもアリじゃないのかと思ったわけよ。
適切な見出しが思い浮かばなかったときは
●とか
段落その２とか
書いとけばいいんじゃないかな。
適切な見出しがすべての段落で書けなくても
見出しを配置することで文書構造がわかりやすくなるなら
それはそれでStrictとしてもアリじゃないのかと思ったわけよ。
適切な見出しが思い浮かばなかったときは
●とか
段落その２とか
書いとけばいいんじゃないかな。
続き
で、その適切じゃない見出しを表示するかどうかは
編集(CSS)の裁量でいいんじゃないかと。
で、その適切じゃない見出しを表示するかどうかは
編集(CSS)の裁量でいいんじゃないかと。
69 ：Name_Not_Found：02/04/15 13:52 ID:YdZzKfIG
>>66
> やはりHTMLは文学作品をマークアップするための言語じゃないってことか。
ま、ハイパーテキストをマークアップするための言語なんでしょね。
文学作品のための文書型があるだろうと思って検索してたらこんなん出てきた。
http://www2s.biglobe.ne.jp/~Taiju/tei_myu6.htm
XML 化もされてるようだから、 XHTML に埋め込むのは手かもしれない。
# 古いブラウザにおける表示とかは限りなく無視になるけど。
> やはりHTMLは文学作品をマークアップするための言語じゃないってことか。
ま、ハイパーテキストをマークアップするための言語なんでしょね。
文学作品のための文書型があるだろうと思って検索してたらこんなん出てきた。
http://www2s.biglobe.ne.jp/~Taiju/tei_myu6.htm
XML 化もされてるようだから、 XHTML に埋め込むのは手かもしれない。
# 古いブラウザにおける表示とかは限りなく無視になるけど。
70 ：Name_Not_Found：02/04/15 15:25 ID:Ng7Rp0mE
71 ：茶文字 ◆xELvisFU ：02/04/15 15:49 ID:OowI5Pwu
いっそのこと、文学作品の各章をulのliでマークアップしちまえ。
……2割くらい本気で言ってみるテスト。
……2割くらい本気で言ってみるテスト。
72 ：茶文字 ◆xELvisFU ：02/04/15 15:49 ID:OowI5Pwu
間違えた。ulぢゃなくてolだな。
73 ：Name_Not_Found：02/04/15 16:59 ID:VYCv6PDt
Strict的（かつ、個人的）には、やっぱ<div>埋めかなぁ。
やっぱ妥協せざるをえない気もする。
#XML方面が一番良いんだろうけど、古いUAは無視ってことか。
やっぱ妥協せざるをえない気もする。
#XML方面が一番良いんだろうけど、古いUAは無視ってことか。
74 ：Name_Not_Found：02/04/15 18:12 ID:YdZzKfIG
>>73
もともと HTML で記述できる類のデータではないものを扱う場合に
必ずとついて回る問題だよね。
精確な記述を重視するなら HTML は除外されるべきで
対応 UA の問題が出てくるけれど
HTML を選べば情報が欠けたり歪んだりするのを回避できない。
HTML 版と XML 版を両方用意する、あたりが現状では最善策なのかな。
もともと HTML で記述できる類のデータではないものを扱う場合に
必ずとついて回る問題だよね。
精確な記述を重視するなら HTML は除外されるべきで
対応 UA の問題が出てくるけれど
HTML を選べば情報が欠けたり歪んだりするのを回避できない。
HTML 版と XML 版を両方用意する、あたりが現状では最善策なのかな。
75 ：Name_Not_Found：02/04/15 19:19 ID:f1Ip5w2R
話が逸れるんですが、散文詩か何か、特殊な改行に作者が意味を
見出している場合文書を、pdf や独自の XML / SGML を使わず、
飽くまで HTML / XHTML 文書にしたかったら、やっぱり pre?
見出している場合文書を、pdf や独自の XML / SGML を使わず、
飽くまで HTML / XHTML 文書にしたかったら、やっぱり pre?
>>53
文章の単位は段落であるが、段落の下の単位を作りたいとき、それはspanではできない。spanは入れ子になるので段落の下の単位がオーバーラップし、ふさわしくない。
特に詩歌や、詩歌的な散文などの文書は段落の下の単位が必要である。そのようなときbrは物理的というよりむしろ論理的な役割を果たす。
>>56
何のためにdiv class="section"で囲むか、だ。
iso-htmlじゃないけれど、h1～h6の要素は本質的に階層構造を持っている。
改めてdiv class="section"と記述するのは冗長かと。
文章の単位は段落であるが、段落の下の単位を作りたいとき、それはspanではできない。spanは入れ子になるので段落の下の単位がオーバーラップし、ふさわしくない。
特に詩歌や、詩歌的な散文などの文書は段落の下の単位が必要である。そのようなときbrは物理的というよりむしろ論理的な役割を果たす。
>>56
何のためにdiv class="section"で囲むか、だ。
iso-htmlじゃないけれど、h1～h6の要素は本質的に階層構造を持っている。
改めてdiv class="section"と記述するのは冗長かと。
>>66
文学作品に見出しの階層構造を要求するのは無理がある。段落さえ無理がある。
文章の一部を引用したり、途中にリンクしたりできない(できたとしても、あまり意味がない。文脈の中でその部分が生きてくる)というのが文学作品。WWWに向いてない。
しかし、WWWで公開する以上、ある程度無理があっても見出し・段落(見出しは無理でも、せめて段落だけでも)の構造を作っていくべきだろう。
文学作品に見出しの階層構造を要求するのは無理がある。段落さえ無理がある。
文章の一部を引用したり、途中にリンクしたりできない(できたとしても、あまり意味がない。文脈の中でその部分が生きてくる)というのが文学作品。WWWに向いてない。
しかし、WWWで公開する以上、ある程度無理があっても見出し・段落(見出しは無理でも、せめて段落だけでも)の構造を作っていくべきだろう。
79 ：Name_Not_Found：02/04/15 20:04 ID:YdZzKfIG
>>77、>>79
ご意見サンクス。
元々 HTML には向いていないものを、しかも、意味付けと表示は別けるべしの
strict スレに書いているので、自分の質問がそもそもムリが有ったんですが、
非常に参考になりました。
ご意見サンクス。
元々 HTML には向いていないものを、しかも、意味付けと表示は別けるべしの
strict スレに書いているので、自分の質問がそもそもムリが有ったんですが、
非常に参考になりました。
>>76
>iso-htmlじゃないけれど、h1～h6の要素は本質的に階層構造を持っている。
>改めてdiv class="section"と記述するのは冗長かと。
でもXMLとして厳密に考えれば、マーク付けされていない要素は「存在しない」、暗黙的な階層構造も「存在しない」と見なされるので、そこのところはご留意の程を。
hnやhr等はあくまで過渡期の思想に基づいたものということで。
>iso-htmlじゃないけれど、h1～h6の要素は本質的に階層構造を持っている。
>改めてdiv class="section"と記述するのは冗長かと。
でもXMLとして厳密に考えれば、マーク付けされていない要素は「存在しない」、暗黙的な階層構造も「存在しない」と見なされるので、そこのところはご留意の程を。
hnやhr等はあくまで過渡期の思想に基づいたものということで。
82 ：Name_Not_Found：02/04/16 01:14 ID:j0YRGNcM
>>81
そうは言っても、例えばh2の後の文章がbody直下にあるとかでなし。
そうは言っても、例えばh2の後の文章がbody直下にあるとかでなし。
83 ：Name_Not_Found：02/04/16 01:27 ID:8s7/5FuT
>>82
何を論拠に言っているの? ISO－HTML?
W3C の仕様には寧ろこんな一文が書いてあるのだが?
>The following example shows how to use the DIV element to associate a heading with the document section that follows it.
http://www.w3.org/TR/html4/struct/global.html#h-7.5.5
何を論拠に言っているの? ISO－HTML?
W3C の仕様には寧ろこんな一文が書いてあるのだが?
>The following example shows how to use the DIV element to associate a heading with the document section that follows it.
http://www.w3.org/TR/html4/struct/global.html#h-7.5.5
85 ：Name_Not_Found：02/04/16 02:48 ID:+3iZjQSb
>>75
勿論 pre 。つーか pre は「ソースコードや詩の整形」の為の物。
今使わずに何時使う…って前々スレあたりでも書いた気がするが。
br は不適切。XHTML 2.0 の l 要素? ならいい気もするが。
>>76
> iso-html じゃないけれど、h1～h6 の要素は本質的に階層構造を持っている。
> 改めて div class="section" と記述するのは冗長かと。
この間の ISO-HTML 論争を読もう…っていうか
どこにリンクを張ったらいいのか分からんが。
h1 が示すのはあくまで <h1>…</h1> が見出しということだけ。
それに続く文章が階層構造を持つことを示すにはまた別のマーク付けが必要。
マーク付け言語ってのは、人間が見たら冗長なのは当然。
勿論 pre 。つーか pre は「ソースコードや詩の整形」の為の物。
今使わずに何時使う…って前々スレあたりでも書いた気がするが。
br は不適切。XHTML 2.0 の l 要素? ならいい気もするが。
>>76
> iso-html じゃないけれど、h1～h6 の要素は本質的に階層構造を持っている。
> 改めて div class="section" と記述するのは冗長かと。
この間の ISO-HTML 論争を読もう…っていうか
どこにリンクを張ったらいいのか分からんが。
h1 が示すのはあくまで <h1>…</h1> が見出しということだけ。
それに続く文章が階層構造を持つことを示すにはまた別のマーク付けが必要。
マーク付け言語ってのは、人間が見たら冗長なのは当然。
>>84
普通の状態だと、標題にドキュメント・セクションは関連付けられない
からわざわざ汎用属性の div 使って、class="section" とか書いている、
って読めないか？
つまり、標題は飽くまで標題で、それ自体階層的構造(h1 ～ h6) は有していても
続くドキュメント・セクションは、標題に続いているか、body 直下だかは
仕様は特にさだめていない、という話だ。
普通の状態だと、標題にドキュメント・セクションは関連付けられない
からわざわざ汎用属性の div 使って、class="section" とか書いている、
って読めないか？
つまり、標題は飽くまで標題で、それ自体階層的構造(h1 ～ h6) は有していても
続くドキュメント・セクションは、標題に続いているか、body 直下だかは
仕様は特にさだめていない、という話だ。
>>86
なんか噛み合ってないな。
そこまでやって表題とドキュメントセクションを
関連付ける必要があるのか?と言うことだ。
どうしても関連つけたければdlのほうが確実だろ?
まあ、俺も厳密にやりたくなったらdivの入れ子を
グダグダ書いちゃうとは思うんだけどな。
body直下うんぬんは
<body>ほにゃらら</body>じゃなくて
<body><p>ほにゃらら</p></body>くらいにはなってるから
問題ないマークアップじゃないか?ってくらいで。
なんか噛み合ってないな。
そこまでやって表題とドキュメントセクションを
関連付ける必要があるのか?と言うことだ。
どうしても関連つけたければdlのほうが確実だろ?
まあ、俺も厳密にやりたくなったらdivの入れ子を
グダグダ書いちゃうとは思うんだけどな。
body直下うんぬんは
<body>ほにゃらら</body>じゃなくて
<body><p>ほにゃらら</p></body>くらいにはなってるから
問題ないマークアップじゃないか?ってくらいで。
88 ：Name_Not_Found：02/04/16 14:23 ID:9RBJYb63
div class="section" って結構見かけるマークアップだけど
使い方は人それぞれだよね、意外と。
hn ごとに几帳面にマークアップする人もいれば
例えば h2 だけ div でくくって h3 以下はフラット、みたいな人も多い。
使い方は人それぞれだよね、意外と。
hn ごとに几帳面にマークアップする人もいれば
例えば h2 だけ div でくくって h3 以下はフラット、みたいな人も多い。
89 ：茶文字 ◆xELvisFU ：02/04/16 16:15 ID:WJlDgajI
90 ：茶文字 ◆xELvisFU ：02/04/16 16:19 ID:WJlDgajI
>>86-87
hnと各pが関連性を持っていないのは、やむを得ない「落としどころ」だったのかも知れない。
===== sample =====
<h1>Web制作板について</h1>
<h2>Web制作板とは</h2>
<p>クライアントサイドのWeb制作について議論する掲示板群です。</p>
<h2>プログラミングについて</h2>
<p>JavaScriptのようなクライアントサイドのスクリプトはこの板で。
PerlやPHPなどのサーバサイドプログラミングはWebProg板で。</p>
<p class="attention">２ちゃんねるは「ハッキングから今夜のおかずまで」をモットーにした巨大匿名掲示板群です。Web制作板もこの中に含まれます。</p>
===== sample =====
上記のようなソースの場合、attentionのクラスを与えたpはh1直下という意図があるんだけど
(つまり<h2>プログラミングについて</h2>の直下ではない)
HTMLのマークアップはこういう構成を表現できない。
このあたりは現行HTMLの限界ってとこなんじゃないかな。
連レスでｽﾏｿが、もういっちょ続ける。
hnと各pが関連性を持っていないのは、やむを得ない「落としどころ」だったのかも知れない。
===== sample =====
<h1>Web制作板について</h1>
<h2>Web制作板とは</h2>
<p>クライアントサイドのWeb制作について議論する掲示板群です。</p>
<h2>プログラミングについて</h2>
<p>JavaScriptのようなクライアントサイドのスクリプトはこの板で。
PerlやPHPなどのサーバサイドプログラミングはWebProg板で。</p>
<p class="attention">２ちゃんねるは「ハッキングから今夜のおかずまで」をモットーにした巨大匿名掲示板群です。Web制作板もこの中に含まれます。</p>
===== sample =====
上記のようなソースの場合、attentionのクラスを与えたpはh1直下という意図があるんだけど
(つまり<h2>プログラミングについて</h2>の直下ではない)
HTMLのマークアップはこういう構成を表現できない。
このあたりは現行HTMLの限界ってとこなんじゃないかな。
連レスでｽﾏｿが、もういっちょ続ける。
91 ：茶文字 ◆xELvisFU ：02/04/16 16:28 ID:WJlDgajI
hnに明確な構造を与えるためのDTD改善案
===== sample =====
<h1 value="Web制作板について">
<h2 value="Web制作板とは">
<p>クライアントサイドのWeb制作について議論する掲示板群です。</p>
</h2>
<h2 value="プログラミングについて">
<p>JavaScriptのようなクライアントサイドのスクリプトはこの板で。
PerlやPHPなどのサーバサイドプログラミングはWebProg板で。
クレクレ厨はﾀﾞｳｿ板、レンタルサーバについてはレン鯖板へどうぞ。</p>
</h2>
<p class="attention">２ちゃんねるは「ハッキングから今夜のおかずまで」をモットーにした巨大匿名掲示板群です。Web制作板もこの中に含まれます。</p>
</h1>
===== sample =====
現行hnは「見出しの文言をマークアップする」のであって、
見出しと本文の主従関係を表現できない。
見出しには追従する本文が伴うはずだから、追従する本文の末尾までを
マークアップするものとする。
見出しの文言は適切な属性を与える(例ではvalueをあててみた)。
後方互換性だのマークアップする文章の種類(詩だの小説だの技術文章だの)によって
不具合もありそうだが、この方法だとUAが見出しを抽出して
目次を自動作成したりするのにｳﾏｰな気がする。
ま、何となく思いついただけなので叩かれ覚悟ですが（ｗ
# 長くなってｽﾏｿ
===== sample =====
<h1 value="Web制作板について">
<h2 value="Web制作板とは">
<p>クライアントサイドのWeb制作について議論する掲示板群です。</p>
</h2>
<h2 value="プログラミングについて">
<p>JavaScriptのようなクライアントサイドのスクリプトはこの板で。
PerlやPHPなどのサーバサイドプログラミングはWebProg板で。
クレクレ厨はﾀﾞｳｿ板、レンタルサーバについてはレン鯖板へどうぞ。</p>
</h2>
<p class="attention">２ちゃんねるは「ハッキングから今夜のおかずまで」をモットーにした巨大匿名掲示板群です。Web制作板もこの中に含まれます。</p>
</h1>
===== sample =====
現行hnは「見出しの文言をマークアップする」のであって、
見出しと本文の主従関係を表現できない。
見出しには追従する本文が伴うはずだから、追従する本文の末尾までを
マークアップするものとする。
見出しの文言は適切な属性を与える(例ではvalueをあててみた)。
後方互換性だのマークアップする文章の種類(詩だの小説だの技術文章だの)によって
不具合もありそうだが、この方法だとUAが見出しを抽出して
目次を自動作成したりするのにｳﾏｰな気がする。
ま、何となく思いついただけなので叩かれ覚悟ですが（ｗ
# 長くなってｽﾏｿ
92 ：Name_Not_Found：02/04/16 16:34 ID:I+MDaCp/
>>91
それって、まさにXHTML 2.0で検討されているsection/h要素ではないかと思います。
それって、まさにXHTML 2.0で検討されているsection/h要素ではないかと思います。
94 ：茶文字 ◆xELvisFU ：02/04/16 16:40 ID:WJlDgajI
95 ：Name_Not_Found：02/04/16 17:07 ID:9RBJYb63
>>91 の例の value 属性って、
現行の HTML でいう title 属性ではないだろうかと思った。
現行の HTML でいう title 属性ではないだろうかと思った。
96 ：Name_Not_Found：02/04/16 17:27 ID:5uKjUiUY
属性と要素の違いをもっとよく考えるべきだと思う。
>>91の例で言うと
<h1 value="Web制作板について">
はやっぱりXHTML2の提案みたいに
<section><h>Web制作板について</h>
とするべき。
表示したいなら要素の内容で、
属性はあくまで補助的なものに。
>>91の例で言うと
<h1 value="Web制作板について">
はやっぱりXHTML2の提案みたいに
<section><h>Web制作板について</h>
とするべき。
表示したいなら要素の内容で、
属性はあくまで補助的なものに。
97 ：Name_Not_Found：02/04/16 17:57 ID:0g/GhYHz
title属性が出てきたのでちょい質問させて下さい。スレ違いだったらｽﾏｿ。
img要素にalt属性って付けますよね？title属性も付けますよね？
どう振り分けたらいいのかよくわからんのです。
例
<img src="hogehoge.gif" alt="タイトルロゴ" title="????">
<img src="hogehoge.gif" alt"" title="タイトルロゴ">
<img src="hogehoge.gif" alt="titlelogo" title="タイトルロゴ">
<img src="hogehoge.gif" alt="○○のウェブサイト" title="タイトルロゴ">
どれが一番適切ですか？
img要素にalt属性って付けますよね？title属性も付けますよね？
どう振り分けたらいいのかよくわからんのです。
例
<img src="hogehoge.gif" alt="タイトルロゴ" title="????">
<img src="hogehoge.gif" alt"" title="タイトルロゴ">
<img src="hogehoge.gif" alt="titlelogo" title="タイトルロゴ">
<img src="hogehoge.gif" alt="○○のウェブサイト" title="タイトルロゴ">
どれが一番適切ですか？
98 ：Name_Not_Found：02/04/16 18:00 ID:RA+7w9J3
99 ：Name_Not_Found：02/04/16 18:11 ID:0g/GhYHz
>>98
神崎さんの所は読んだのですが、ヴィジュアル的に用いてる画像は
alt=""に。その場合title属性には何を書けば良いのかなぁと思いまして。
レスありがとうです。スレ汚してごめんなさい。
このスレは勉強になります。
神崎さんの所は読んだのですが、ヴィジュアル的に用いてる画像は
alt=""に。その場合title属性には何を書けば良いのかなぁと思いまして。
レスありがとうです。スレ汚してごめんなさい。
このスレは勉強になります。
100 ：Name_Not_Found：02/04/16 19:11 ID:5LHPwBKk
titleは必須じゃないのだから、無理して書かなくても。
101 ：Name_Not_Found：02/04/16 19:23 ID:RA+7w9J3
102 ：Name_Not_Found：02/04/16 20:47 ID:5N5uI7pq
103 ：茶文字 ◆xELvisFU ：02/04/16 22:09 ID:x6DVCxjy
＞imgのtitle属性
画像につけるtitleなんだから、その絵や写真のタイトルそのものを書くべきなのかと。
たとえばその画像に「春の富士」というタイトルがある場合とか。
単体の画像にタイトルがないなら、特に付与する必要はないのではないかな。
title=""も不要だと思う。
画像につけるtitleなんだから、その絵や写真のタイトルそのものを書くべきなのかと。
たとえばその画像に「春の富士」というタイトルがある場合とか。
単体の画像にタイトルがないなら、特に付与する必要はないのではないかな。
title=""も不要だと思う。
>>81
現在使われている第一世代のHTMLはあまり階層を深くしないために明示的な階層構造をとらずにh1～h6の"暗黙的な階層構造"をとったわけである。
この暗黙的な階層構造は単なる時代遅れと決め付けるのはやめたほうがいい。たとえば次のXMLを例にとる。
<section><h>見出し1</h><p>段落1</p><section><h>見出し2</h><p>[段落2]</p></section>
この例では、段落2は段落1の下層に位置している。しかし、自然な言葉の流れでは、この二つの段落は等価値を持っていることがしばしばある。現在の方式を使えば、作者はこの仕組みを実現できる。
もちろんdivで補助し、"暗黙的な階層構造"を明確化することもできるが、それはこのHTMLの仕組みを壊すことでもある。特に明確な階層構造のある文書でもない限り、このような冗長な記述はすべきではない。
現在使われている第一世代のHTMLはあまり階層を深くしないために明示的な階層構造をとらずにh1～h6の"暗黙的な階層構造"をとったわけである。
この暗黙的な階層構造は単なる時代遅れと決め付けるのはやめたほうがいい。たとえば次のXMLを例にとる。
<section><h>見出し1</h><p>段落1</p><section><h>見出し2</h><p>[段落2]</p></section>
この例では、段落2は段落1の下層に位置している。しかし、自然な言葉の流れでは、この二つの段落は等価値を持っていることがしばしばある。現在の方式を使えば、作者はこの仕組みを実現できる。
もちろんdivで補助し、"暗黙的な階層構造"を明確化することもできるが、それはこのHTMLの仕組みを壊すことでもある。特に明確な階層構造のある文書でもない限り、このような冗長な記述はすべきではない。
105 ：Name_Not_Found：02/04/16 22:55 ID:nYQ37MSg
情報求む。それと、HTML4.01strictで使用するならobjectは
<object data="***.swf" type="application/x-shockwave-flash">
でいいんだよね？
<object data="***.swf" type="application/x-shockwave-flash">
でいいんだよね？
106 ：Name_Not_Found：02/04/16 23:08 ID:t6qH1+KJ
>105
>http://www.macromedia.com/jp/support/director/ts/documents/dr0112.html
例:
<object classid"clsid:166B1BCA-3F9C-11CF-8075-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/director/sw.cab#version=7,0,0,0"
width="512"
height="480"
name="MovieName">
<param name="SRC" value="MYMOVIE.DCR">
</object>
>http://www.macromedia.com/jp/support/director/ts/documents/dr0112.html
例:
<object classid"clsid:166B1BCA-3F9C-11CF-8075-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/director/sw.cab#version=7,0,0,0"
width="512"
height="480"
name="MovieName">
<param name="SRC" value="MYMOVIE.DCR">
</object>
108 ：Name_Not_Found：02/04/16 23:46 ID:5N5uI7pq
>>104
> 現在使われている第一世代のHTMLはあまり階層を深くしないために
> 明示的な階層構造をとらずにh1～h6の"暗黙的な階層構造"
> をとったわけである。
そんな話は初耳です。>>104 の想像でないならソースキボヌ。
> 特に明確な階層構造のある文書でもない限り
君が >>76 で「h1～h6 の要素は本質的に階層構造を持っている」
と述べているように、つまるところ h1-h6 が出現するような文書には
常に階層構造が存在しているんじゃないのか?
それともそれは「本質的」ではあっても「明確」なものではないってことか?
>>>105
マルチポストはやめようね。
> 現在使われている第一世代のHTMLはあまり階層を深くしないために
> 明示的な階層構造をとらずにh1～h6の"暗黙的な階層構造"
> をとったわけである。
そんな話は初耳です。>>104 の想像でないならソースキボヌ。
> 特に明確な階層構造のある文書でもない限り
君が >>76 で「h1～h6 の要素は本質的に階層構造を持っている」
と述べているように、つまるところ h1-h6 が出現するような文書には
常に階層構造が存在しているんじゃないのか?
それともそれは「本質的」ではあっても「明確」なものではないってことか?
>>>105
マルチポストはやめようね。
109 ：Name_Not_Found：02/04/16 23:58 ID:9z4eIFXU
>>104
>> <section><h>見出し1</h><p>段落1</p><section><h>見出し2</h><p>[段落2]</p></section>
well-formattedなxmlを書いて頂けませんか？
>> <section><h>見出し1</h><p>段落1</p><section><h>見出し2</h><p>[段落2]</p></section>
well-formattedなxmlを書いて頂けませんか？
well-formatted -> well-formed
111 ：Name_Not_Found：02/04/17 00:01 ID:EOQ6JDMC
112 ：Name_Not_Found：02/04/17 00:07 ID:8BEjvq/c
113 ：Name_Not_Found：02/04/17 00:10 ID:EOQ6JDMC
>>112
そうなんだよ。。。ＵＡ無視すればできるんだよ。
とりあうえず。ＮＮ6.21とＩＥ6.0とＭｏｚｉｌａ0.9.9には表示はできたんだ。（ウィンドウズ）
Ｏｐｅｒａ6.01ではダメだった。。。
正しい。HTML4.01strictとはいえないやり方だろうが、
W3CのHTML4.01strictチャックページではノーエラーだった。
そうなんだよ。。。ＵＡ無視すればできるんだよ。
とりあうえず。ＮＮ6.21とＩＥ6.0とＭｏｚｉｌａ0.9.9には表示はできたんだ。（ウィンドウズ）
Ｏｐｅｒａ6.01ではダメだった。。。
正しい。HTML4.01strictとはいえないやり方だろうが、
W3CのHTML4.01strictチャックページではノーエラーだった。
114 ：Name_Not_Found：02/04/17 00:11 ID:EOQ6JDMC
>>113
すまん。。。風呂上りで誤字脱字が多い。
すまん。。。風呂上りで誤字脱字が多い。
115 ：Name_Not_Found：02/04/17 00:31 ID:58uXGEtJ
title属性の質問をした者です。
>>100-103さん
有り難う御座います。
特に無理して書こうと思ってたわけでは無いんですが、どう判別すべき
なのかがイマイチ理解できなかったんです。ｽﾏｿ……。
>>茶文字さん
非常にわかりやすい説明有り難う御座います。
"ゴッホのひまわり"こんな感じですね。ホント勉強になります。はい。
>>100-103さん
有り難う御座います。
特に無理して書こうと思ってたわけでは無いんですが、どう判別すべき
なのかがイマイチ理解できなかったんです。ｽﾏｿ……。
>>茶文字さん
非常にわかりやすい説明有り難う御座います。
"ゴッホのひまわり"こんな感じですね。ホント勉強になります。はい。
116 ：Name_Not_Found：02/04/17 05:13 ID:SR/l9An0
>>113
そういうページ作ってて楽しい？中途半端なデザインになる上、アクセシビリティも落ちてお前はStrictの何に共感したんだ？と問い詰めたくなる。
そういうページ作ってて楽しい？中途半端なデザインになる上、アクセシビリティも落ちてお前はStrictの何に共感したんだ？と問い詰めたくなる。
117 ：116：02/04/17 05:15 ID:SR/l9An0
Strict知ってる奴が100点取れないのはおかしいしね。
チェックするまでもないと思う。
チェックするまでもないと思う。
118 ：Name_Not_Found：02/04/17 05:39 ID:yHsRMySo
>>117
うん？
＞Strict知ってる奴が100点取れないのはおかしいしね。
＞チェックするまでもないと思う。
100点てなんだ？ 君はテストでもしたのか？
フラッシュがどのUAでも見れるようにできるようにするということは、
アクセシビリティがおちるということなのか？
Strictにこだわるからこその問題だろうが。
Strict以外だった何も気にしないで、マクロメディア特製タグ（パブリッシュ）
をそのまま使う。
逆にStrictはフラッシュを使わないのか？筵、お前は使えないのだろうと問い詰めたい。
答えが出せないならばレスの必要はない。
うん？
＞Strict知ってる奴が100点取れないのはおかしいしね。
＞チェックするまでもないと思う。
100点てなんだ？ 君はテストでもしたのか？
フラッシュがどのUAでも見れるようにできるようにするということは、
アクセシビリティがおちるということなのか？
Strictにこだわるからこその問題だろうが。
Strict以外だった何も気にしないで、マクロメディア特製タグ（パブリッシュ）
をそのまま使う。
逆にStrictはフラッシュを使わないのか？筵、お前は使えないのだろうと問い詰めたい。
答えが出せないならばレスの必要はない。
119 ：Name_Not_Found：02/04/17 06:10 ID:0eNO9v4W
>>117
> strict 知ってる奴が
お前は「strict を知っている = DTD を読める」だとでも思っているのかと小一時間
> チェックするまでもないと思う。
お前は typo したことがないのかと小一時間
> strict 知ってる奴が
お前は「strict を知っている = DTD を読める」だとでも思っているのかと小一時間
> チェックするまでもないと思う。
お前は typo したことがないのかと小一時間
120 ：Name_Not_Found：02/04/17 07:49 ID:4OHTuNu2
>>112
> だって、Flash自体がStrictになじまないからね。
インライン表示/再生できることを前提にするのは問題がある。それだけでしょ。
別に普通の画像等を HTML に埋め込む場合と同じだと思うんだけど。 Strict 的に。
> だって、Flash自体がStrictになじまないからね。
インライン表示/再生できることを前提にするのは問題がある。それだけでしょ。
別に普通の画像等を HTML に埋め込む場合と同じだと思うんだけど。 Strict 的に。
121 ：Name_Not_Found：02/04/17 10:15 ID:Fnbc7w1Z
わざわざ対応UA減らしてまでStrictにこだわるのって何？
俺には自己満足にしか見えないのだが俺の頭が固いだけ？
俺には自己満足にしか見えないのだが俺の頭が固いだけ？
122 ：茶文字 ◆xELvisFU ：02/04/17 10:21 ID:KS2kURoK
確かにインラインでなくてもよいならa要素で直接呼び出すようにすればいいな。
これがどうしても受け容れられないとすると、
少なくともWAIの提案しているﾕｰｻﾞﾋﾞﾘﾁ/ｱｸｾｼﾋﾞﾘﾁなんかの方向性とは違ってくると思うんだが。
これもStrictと無縁ではあるまい。
これがどうしても受け容れられないとすると、
少なくともWAIの提案しているﾕｰｻﾞﾋﾞﾘﾁ/ｱｸｾｼﾋﾞﾘﾁなんかの方向性とは違ってくると思うんだが。
これもStrictと無縁ではあるまい。
123 ：Name_Not_Found：02/04/17 10:22 ID:Fnbc7w1Z
ちなみに、IE、ネスケ(Mozilla)、OperaくらいしかFlash対応してないはず。
う～ん……自己満足にしか見えない。俺ならUA絞ったんだから使える機能は使いたいと思うけどな。
どうせFlashページ見る奴はStrictのSの字も知らない奴らだ。管理が面倒なだけだと思う。
う～ん……自己満足にしか見えない。俺ならUA絞ったんだから使える機能は使いたいと思うけどな。
どうせFlashページ見る奴はStrictのSの字も知らない奴らだ。管理が面倒なだけだと思う。
124 ：Name_Not_Found：02/04/17 10:24 ID:I/zPvOBN
125 ：Name_Not_Found：02/04/17 10:32 ID:Fnbc7w1Z
>>124
俺が言ったのは、本来のStrictから対応UAを減らしてまでFlashに～ってこと。
123でも言ったようにTranstionalやFramesetと変わらないんじゃないか？
TranstionalでもURL書けば標準モードで機能するし。
俺が言ったのは、本来のStrictから対応UAを減らしてまでFlashに～ってこと。
123でも言ったようにTranstionalやFramesetと変わらないんじゃないか？
TranstionalでもURL書けば標準モードで機能するし。
126 ：121-123-125：02/04/17 10:35 ID:Fnbc7w1Z
俺自身もStrictとFlash使っているんでこの話にかなり興味がある。
上記の問題を解決できる方法があるのなら探そうと努力はしている。
今のところ、XHTML1.1とFlashMX用にXHTML1.0Transtional使ってますけど。
上記の問題を解決できる方法があるのなら探そうと努力はしている。
今のところ、XHTML1.1とFlashMX用にXHTML1.0Transtional使ってますけど。
127 ：Name_Not_Found：02/04/17 10:36 ID:I/zPvOBN
×あれば無いのでは？
○あればよいのでは？
○あればよいのでは？
129 ：121-123-125：02/04/17 10:43 ID:Fnbc7w1Z
alt=""ってことかな。
131 ：Name_Not_Found：02/04/17 11:39 ID:MtOjIZVZ
ゴタゴタいう前に、ホームページ制作王を買いましょう。
これで問題解決。貴方のサイトもプロの仕上がり。
これで問題解決。貴方のサイトもプロの仕上がり。
132 ：Name_Not_Found：02/04/17 11:56 ID:4OHTuNu2
>>121
> わざわざ対応UA減らしてまでStrictにこだわるのって何？
漏れの場合の理由は、未対応 UA のユーザに対して
その UA がいつまでも快適に使えるわけじゃないことを現実として知って欲しいから。
ブラウザが一つじゃないことやアップデートできること、
それでも見られないものが存在すること、でもそれは仕方のないこと
…と、そんなことを知るきっかけになるなら、と思ってる。
まあ自己満足みたいなものだが。
まだ過渡期であり Strict に移行するには無理があると判断したなら、
移行期型の Transitional を使えばいい。
移行期のための移行期型を、ここで使わずしてどこで使う？
物理要素を許可してこそいるけど推奨してるわけじゃなし、
Transitional であっても論理マークアップが求められることには変わりない。
> わざわざ対応UA減らしてまでStrictにこだわるのって何？
漏れの場合の理由は、未対応 UA のユーザに対して
その UA がいつまでも快適に使えるわけじゃないことを現実として知って欲しいから。
ブラウザが一つじゃないことやアップデートできること、
それでも見られないものが存在すること、でもそれは仕方のないこと
…と、そんなことを知るきっかけになるなら、と思ってる。
まあ自己満足みたいなものだが。
まだ過渡期であり Strict に移行するには無理があると判断したなら、
移行期型の Transitional を使えばいい。
移行期のための移行期型を、ここで使わずしてどこで使う？
物理要素を許可してこそいるけど推奨してるわけじゃなし、
Transitional であっても論理マークアップが求められることには変わりない。
133 ：茶文字 ◆xELvisFU ：02/04/17 19:29 ID:LhyN3cjF
Flashに限った話ではないが、そういったマルチメディアファイルを
多くのブラウザでPlug-inなしに閲覧できるようになる可能性はある。
で、たとえばFlashだってキーボードによるアサインなどに対応するようになれば、
よく言われるアクセシビリティーの低さをある程度克服できる可能性はある。
つまり、Flashなどのマルチメディアファイルだって今は過渡期なのかも知れないってこと。
XHTMLの規格とマルチメディアコンテンツのどちらの側からも歩み寄りがあれば、
StrictなXHTMLから画像と同じような気軽さでそれらにアクセスすることも
できるようになるかも知れない。
今のところobject要素の実装が貧弱という現実があって難しいんだろうけど、
UAの実装だけが問題ではないような気がする。
多くのブラウザでPlug-inなしに閲覧できるようになる可能性はある。
で、たとえばFlashだってキーボードによるアサインなどに対応するようになれば、
よく言われるアクセシビリティーの低さをある程度克服できる可能性はある。
つまり、Flashなどのマルチメディアファイルだって今は過渡期なのかも知れないってこと。
XHTMLの規格とマルチメディアコンテンツのどちらの側からも歩み寄りがあれば、
StrictなXHTMLから画像と同じような気軽さでそれらにアクセスすることも
できるようになるかも知れない。
今のところobject要素の実装が貧弱という現実があって難しいんだろうけど、
UAの実装だけが問題ではないような気がする。
134 ：Name_Not_Found：02/04/17 23:42 ID:/7yVPWHc
ageておきます。
135 ：Name_Not_Found：02/04/18 09:58 ID:qq0aViJU
<h3 xml:lang="en">ゲーム名</h3>
<ul>
<li xml:lang="ja">ジャンル／RPG</li>
<li xml:lang="ja">動作機種／Windows98/Me/NT4.0/2000/XP日本語版（Windows2000/XP推奨）</li>
</ul>
<h4 xml:lang="ja">動作環境</h4>
<ul>
<li xml:lang="ja">ＣＰＵ／PentiumIII 500MHz以上（Pentium4 1.5GHz以上推奨）</li>
<li xml:lang="ja">メモリ／64MB以上（256MB以上推奨）</li>
<li xml:lang="ja">ＨＤ空き容量／未定</li>
<li xml:lang="ja">ビデオカード／GeForce2MX以上（GeForce3以上推奨）</li>
<li xml:lang="ja">ディスプレイ／640x480 FullColor表示可能なもの</li>
<li xml:lang="ja">ジョイパッド／4ボタン以上（8ボタン以上推奨）</li>
<li xml:lang="ja">.NET Framework必須</li>
</ul>
と書いているんですが、「／」が音声ブラウザでどう読み取られるのか気になっています。不適切な気がしてなりません。さらに、見栄えまで悪い。
本来は、ここ＜ttp://www.exe-create.co.jp/products/f2_main.html＞のように見せたり、音声で聞かせたいんです。
このような場合、どの要素が適切ですか？
表なのでやはりTableでしょうか？また、Table以外の要素で出来たとして、表にTable以外をわざわざ使うのはどうなんでしょうか？
<ul>
<li xml:lang="ja">ジャンル／RPG</li>
<li xml:lang="ja">動作機種／Windows98/Me/NT4.0/2000/XP日本語版（Windows2000/XP推奨）</li>
</ul>
<h4 xml:lang="ja">動作環境</h4>
<ul>
<li xml:lang="ja">ＣＰＵ／PentiumIII 500MHz以上（Pentium4 1.5GHz以上推奨）</li>
<li xml:lang="ja">メモリ／64MB以上（256MB以上推奨）</li>
<li xml:lang="ja">ＨＤ空き容量／未定</li>
<li xml:lang="ja">ビデオカード／GeForce2MX以上（GeForce3以上推奨）</li>
<li xml:lang="ja">ディスプレイ／640x480 FullColor表示可能なもの</li>
<li xml:lang="ja">ジョイパッド／4ボタン以上（8ボタン以上推奨）</li>
<li xml:lang="ja">.NET Framework必須</li>
</ul>
と書いているんですが、「／」が音声ブラウザでどう読み取られるのか気になっています。不適切な気がしてなりません。さらに、見栄えまで悪い。
本来は、ここ＜ttp://www.exe-create.co.jp/products/f2_main.html＞のように見せたり、音声で聞かせたいんです。
このような場合、どの要素が適切ですか？
表なのでやはりTableでしょうか？また、Table以外の要素で出来たとして、表にTable以外をわざわざ使うのはどうなんでしょうか？
136 ：Name_Not_Found：02/04/18 10:00 ID:qq0aViJU
質問なのにsageてしまいました。
<h3 xml:lang="en">ゲーム名</h3>これのlang="en"ですが、本来は英文字のタイトルですので。って、質問に入ってないか。
<h3 xml:lang="en">ゲーム名</h3>これのlang="en"ですが、本来は英文字のタイトルですので。って、質問に入ってないか。
137 ：Name_Not_Found：02/04/18 10:27 ID:0tKoertu
>>135
「／」が気になるなら、「Windows98/Me/NT4.0/2000/XP」も考えた方がいいかもね。
「／」が気になるなら、「Windows98/Me/NT4.0/2000/XP」も考えた方がいいかもね。
138 ：Name_Not_Found：02/04/18 10:46 ID:uq9jSaEE
>>135
というか、一々 xml:lang="ja" を指定する必要はない。
日本語がメインなんだろうから、xml:lang="ja" はもっと上位の要素に
一回だけ指定して、例外的な言語(例えば xml:lang="en")を
その都度指定するようにした方が楽。
要素については table でいいような気がするが。
多分それが一番見易いと思う。
というか、一々 xml:lang="ja" を指定する必要はない。
日本語がメインなんだろうから、xml:lang="ja" はもっと上位の要素に
一回だけ指定して、例外的な言語(例えば xml:lang="en")を
その都度指定するようにした方が楽。
要素については table でいいような気がするが。
多分それが一番見易いと思う。
139 ：Name_Not_Found：02/04/18 10:57 ID:tkUsmvON
とりあえず英数字全部半角にする方が。
しかも最低と推奨の開きが(わらい
ま、それはいいとして、/ が区切りなら、
<dl>
<dt>CPU</dt>
<dd>Pentium3 500MHz以上（Pentium4 1.5GHz以上推奨）</dd>
<dt>メモリ</dt>
<dd>64MB以上（256MB以上推奨）</dd>
<dt>HD空き容量</dt>
<dd>未定</dd>
<dt>ビデオカード</dt>
<dd>GeForce2MX以上（GeForce3以上推奨）</dd>
( 中略 )
</dl>
とした方が。
ついでに、III != 3 。オーラル UA にかけたら…、死すプ莉状態……（´д｀;）
動作環境も dd 重ねるか。
やっぱりこの場合は表がいいのかも。
しかも最低と推奨の開きが(わらい
ま、それはいいとして、/ が区切りなら、
<dl>
<dt>CPU</dt>
<dd>Pentium3 500MHz以上（Pentium4 1.5GHz以上推奨）</dd>
<dt>メモリ</dt>
<dd>64MB以上（256MB以上推奨）</dd>
<dt>HD空き容量</dt>
<dd>未定</dd>
<dt>ビデオカード</dt>
<dd>GeForce2MX以上（GeForce3以上推奨）</dd>
( 中略 )
</dl>
とした方が。
ついでに、III != 3 。オーラル UA にかけたら…、死すプ莉状態……（´д｀;）
動作環境も dd 重ねるか。
やっぱりこの場合は表がいいのかも。
140 ：Name_Not_Found：02/04/18 11:04 ID:qq0aViJU
やはりこれしか方法がないんだろうか…
<div>
<h3 xml:lang="en">Game Title</h3>
<table summary="Game Title">
<tr><td xml:lang="ja">ジャンル</td> <td xml:lang="en">RPG</td> </tr>
<tr><td xml:lang="ja">動作機種</td> <td xml:lang="ja">Windows98/Me/NT4.0/2000/XP日本語版（Windows2000/XP推奨）</td> </tr>
</table>
<h4 xml:lang="ja">動作環境</h4>
<table summary="動作環境">
<tr><th></th> <th xml:lang="ja">必須環境</th> <th xml:lang="en">推奨環境</th> </tr>
<tr><td xml:lang="en">CPU</td> <td xml:lang="en">Pentium3 500MHz</td> <td xml:lang="ja">Pentium4 1.5GHz以上</td> </tr>
<tr><td xml:lang="ja">メモリ</td> <td xml:lang="en">64MB</td> <td xml:lang="ja">256MB以上</td> </tr>
<tr><td xml:lang="en">HDD</td> <td xml:lang="ja">未定</td> <td></td> </tr>
<tr><td xml:lang="ja">ビデオカード</td> <td xml:lang="en">GeForce2MX</td> <td xml:lang="ja">GeForce3以上</td> </tr>
<tr><td xml:lang="ja">ディスプレイ</td> <td xml:lang="en">640x480 HighColor</td> <td></td> </tr>
<tr><td xml:lang="ja">ジョイパッド</td> <td xml:lang="ja">4ボタン</td> <td xml:lang="ja">8ボタン</td> </tr>
<tr><td></td> <td xml:lang="en">.NET Framework</td> <td></td> </tr>
</table>
<hr />
</div>
<div>
<h3 xml:lang="en">Game Title</h3>
<table summary="Game Title">
<tr><td xml:lang="ja">ジャンル</td> <td xml:lang="en">RPG</td> </tr>
<tr><td xml:lang="ja">動作機種</td> <td xml:lang="ja">Windows98/Me/NT4.0/2000/XP日本語版（Windows2000/XP推奨）</td> </tr>
</table>
<h4 xml:lang="ja">動作環境</h4>
<table summary="動作環境">
<tr><th></th> <th xml:lang="ja">必須環境</th> <th xml:lang="en">推奨環境</th> </tr>
<tr><td xml:lang="en">CPU</td> <td xml:lang="en">Pentium3 500MHz</td> <td xml:lang="ja">Pentium4 1.5GHz以上</td> </tr>
<tr><td xml:lang="ja">メモリ</td> <td xml:lang="en">64MB</td> <td xml:lang="ja">256MB以上</td> </tr>
<tr><td xml:lang="en">HDD</td> <td xml:lang="ja">未定</td> <td></td> </tr>
<tr><td xml:lang="ja">ビデオカード</td> <td xml:lang="en">GeForce2MX</td> <td xml:lang="ja">GeForce3以上</td> </tr>
<tr><td xml:lang="ja">ディスプレイ</td> <td xml:lang="en">640x480 HighColor</td> <td></td> </tr>
<tr><td xml:lang="ja">ジョイパッド</td> <td xml:lang="ja">4ボタン</td> <td xml:lang="ja">8ボタン</td> </tr>
<tr><td></td> <td xml:lang="en">.NET Framework</td> <td></td> </tr>
</table>
<hr />
</div>
141 ：Name_Not_Found：02/04/18 11:10 ID:qq0aViJU
あれっ？ここって半角スペース効かないのか…見辛くなった…
>>139
<dl>要素は一応考えていました。
音声ブラウザがTableを読む場合、横一列を読んでいきますから、この場合はTableが良いんですかね。
>>139
<dl>要素は一応考えていました。
音声ブラウザがTableを読む場合、横一列を読んでいきますから、この場合はTableが良いんですかね。
>>140
更に重箱。(私も格段詳しいわけじゃないけどね。
対応 OS は動作環境 table に入れてる方が良いんじゃないかな、なんて。
Strict とは関係なくなってきてるけど。
で、OS は正に対応 OS が列挙、されてる訳だから ul なのかなぁ、とか。
III と同じく、 x != × (乗算記号)とか。
.NET 云々は動作環境ではあるけれども、表の中に押し込む必要は無いんじゃ？ とか。
とかとか煩いなぁ…
それにしても、テキスト形式限定のうｐろだとかあると便利かも。(作れスレみたいに
更に重箱。(私も格段詳しいわけじゃないけどね。
対応 OS は動作環境 table に入れてる方が良いんじゃないかな、なんて。
Strict とは関係なくなってきてるけど。
で、OS は正に対応 OS が列挙、されてる訳だから ul なのかなぁ、とか。
III と同じく、 x != × (乗算記号)とか。
.NET 云々は動作環境ではあるけれども、表の中に押し込む必要は無いんじゃ？ とか。
とかとか煩いなぁ…
それにしても、テキスト形式限定のうｐろだとかあると便利かも。(作れスレみたいに
143 ：Name_Not_Found：02/04/18 11:34 ID:qq0aViJU
>>142
＞対応 OS は動作環境 table に
それはちょっと…（確かに動作環境Tableのほうが見やすいんですけどねんで…）
それをふまえた上での改善点は
1 ジャンル、動作機種は ul で
2 640x480の部分は別の方法で…
2ですが、よくよく考えると解像度ってXGAとかSVGAとかで表現できますよね。
ってことは、VGA HighColor
＞対応 OS は動作環境 table に
それはちょっと…（確かに動作環境Tableのほうが見やすいんですけどねんで…）
それをふまえた上での改善点は
1 ジャンル、動作機種は ul で
2 640x480の部分は別の方法で…
2ですが、よくよく考えると解像度ってXGAとかSVGAとかで表現できますよね。
ってことは、VGA HighColor
144 ：135：02/04/18 11:42 ID:qq0aViJU
>>137
確かに…、Windows 98 Me NT4.0 2000 XPにするか、 , か . で区切ったほうがよさそうですね
>>138
最上位は<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">でUTF-8のマルチランゲージです。enとen-US,en-UKの使い分けが…
Strictで理想を求めるなら文法テストで百点取るだけじゃなく、見え方、聞こえ方にも注意した不がよさそうですね。
確かに…、Windows 98 Me NT4.0 2000 XPにするか、 , か . で区切ったほうがよさそうですね
>>138
最上位は<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">でUTF-8のマルチランゲージです。enとen-US,en-UKの使い分けが…
Strictで理想を求めるなら文法テストで百点取るだけじゃなく、見え方、聞こえ方にも注意した不がよさそうですね。
145 ：Name_Not_Found：02/04/18 11:56 ID:LmFXwXi+
base hrefタグはhead内に入れる必要がありますが、
link rel="stylesheet" hrefよりも前に入れなければいけないのでしょうか。
するとstylesheetをフルパスにする必要がありめんどそうなのですが。
base hrefタグを複数記入して途中で変更するとどういった挙動が起きるのでしょうか。
link rel="stylesheet" hrefよりも前に入れなければいけないのでしょうか。
するとstylesheetをフルパスにする必要がありめんどそうなのですが。
base hrefタグを複数記入して途中で変更するとどういった挙動が起きるのでしょうか。
146 ：Name_Not_Found：02/04/18 12:06 ID:0tKoertu
>>145
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/links.html#h-12.4
> BASE要素は、存在する場合は、HTML文書のHEAD要素において、外部リソースを参照している他のどの要素よりも前に出現しなければならない。
複数記述した場合はの挙動は当然 UA におまかせ。
途中変更もあるだろうし、最初(もしくは最後)のみ有効もありうるし、
不正記述としてすべて無効ももちろんありうる。
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/links.html#h-12.4
> BASE要素は、存在する場合は、HTML文書のHEAD要素において、外部リソースを参照している他のどの要素よりも前に出現しなければならない。
複数記述した場合はの挙動は当然 UA におまかせ。
途中変更もあるだろうし、最初(もしくは最後)のみ有効もありうるし、
不正記述としてすべて無効ももちろんありうる。
147 ：Name_Not_Found：02/04/18 12:10 ID:tkUsmvON
>>146
このスレ的には一個以外は許さんぞ(#ﾟДﾟ)ｺﾞﾙｧ! なんでは。(w
このスレ的には一個以外は許さんぞ(#ﾟДﾟ)ｺﾞﾙｧ! なんでは。(w
148 ：Name_Not_Found：02/04/18 12:20 ID:LmFXwXi+
>>146
base要素はすべての外部リソースを参照している要素よりも前に記述ですか。ではフルパスにします。ありがとうございました。
>>147
やっぱり(#?Д?)コ?ルァ! 言われちゃった。仕様の方を変更してほしいと思うのは私だけ？
base要素はすべての外部リソースを参照している要素よりも前に記述ですか。ではフルパスにします。ありがとうございました。
>>147
やっぱり(#?Д?)コ?ルァ! 言われちゃった。仕様の方を変更してほしいと思うのは私だけ？
149 ：Name_Not_Found：02/04/18 12:25 ID:LmFXwXi+
base targetも
link rel="stylesheet" hrefよりも前に入れなければいけないのでしょうか。
するとターゲットフレーム内にstylesheetが読み込まれるとか。
link rel="stylesheet" hrefよりも前に入れなければいけないのでしょうか。
するとターゲットフレーム内にstylesheetが読み込まれるとか。
150 ：Name_Not_Found：02/04/18 12:38 ID:0tKoertu
base 要素には href 属性が必須。
target 属性があろうがなかろうが link 要素より前。
> するとターゲットフレーム内にstylesheetが読み込まれるとか。
真偽の程は解らんが、ありえない話ではないかもと思った。
target 属性があろうがなかろうが link 要素より前。
> するとターゲットフレーム内にstylesheetが読み込まれるとか。
真偽の程は解らんが、ありえない話ではないかもと思った。
修正。
> base 要素には href 属性が必須。
Strict DTD では、の話ね。元々 Strict に target 属性はないし。
> base 要素には href 属性が必須。
Strict DTD では、の話ね。元々 Strict に target 属性はないし。
>>144
>Strictで理想を求めるなら(略)、見え方、聞こえ方にも注意した不がよさそうですね。
スタイルシートつかえ。
んで>>135は表じゃなくて定義だと思われ。
<h3 xml:lang="en">GameTitle</h3>
<dl xml:lang="ja">
<dt>動作機種</dt>
<dd>
<ul xml:lang="en">
<li>Windows98</li>
<li>Windows<abbr title="Millenium Edition">Me</abbr></li>
</ul>
</dd>
<dt>動作環境</dt>
<dd>
<dl>
<dt>CPU</dt>
<!-- いろいろ -->
</dl>
</dd>
</dl>
>Strictで理想を求めるなら(略)、見え方、聞こえ方にも注意した不がよさそうですね。
スタイルシートつかえ。
んで>>135は表じゃなくて定義だと思われ。
<h3 xml:lang="en">GameTitle</h3>
<dl xml:lang="ja">
<dt>動作機種</dt>
<dd>
<ul xml:lang="en">
<li>Windows98</li>
<li>Windows<abbr title="Millenium Edition">Me</abbr></li>
</ul>
</dd>
<dt>動作環境</dt>
<dd>
<dl>
<dt>CPU</dt>
<!-- いろいろ -->
</dl>
</dd>
</dl>
154 ：茶文字 ◆xELvisFU ：02/04/18 20:23 ID:JS4ZjtYj
おまえら、支援物資ですよ。
http://members6.tsukaeru.net/xelvis/wfm/main.cgi
↑
あぷろだ。拡張子(.txt|.html?|.css|.js)のみ利用可能。
いたずらはいやづら。
# このあぷろだは初心者スレとStrictスレで共用っつーことでひとつよろしく。
http://members6.tsukaeru.net/xelvis/wfm/main.cgi
↑
あぷろだ。拡張子(.txt|.html?|.css|.js)のみ利用可能。
いたずらはいやづら。
# このあぷろだは初心者スレとStrictスレで共用っつーことでひとつよろしく。
155 ：Name_Not_Found：02/04/18 20:46 ID:vs7qOEJh
茶ぷろだ（・∀・）ｲｲ!!
専用あｐろだが( ﾟдﾟ)ﾎｽｨ…と思ってたとこですよ。
ところでCSSやスクリプトスレは不可ですか？
専用あｐろだが( ﾟдﾟ)ﾎｽｨ…と思ってたとこですよ。
ところでCSSやスクリプトスレは不可ですか？
156 ：茶文字 ◆xELvisFU ：02/04/18 21:00 ID:JS4ZjtYj
>>155
CSSスレとJavaScriptスレはたまにまとめて読むだけなんで、
話題に追いついてないんです。
需要があるなら解放しますけど。
何がどういう目的でうｐされているのか把握したいと思っているので、
頻繁に追いかけてないスレはﾁｮﾄつらいかな、とか思ったり。
ま、私がせっせと読むようにすればいいんだけど（ｗ
CSSスレとJavaScriptスレはたまにまとめて読むだけなんで、
話題に追いついてないんです。
需要があるなら解放しますけど。
何がどういう目的でうｐされているのか把握したいと思っているので、
頻繁に追いかけてないスレはﾁｮﾄつらいかな、とか思ったり。
ま、私がせっせと読むようにすればいいんだけど（ｗ
157 ：Name_Not_Found：02/04/18 21:02 ID:eKnIX1xd
>>155
茶ぷろだのネーミングが(・∀・)ｲｲ!
茶ぷろだのネーミングが(・∀・)ｲｲ!
158 ：Name_Not_Found：02/04/18 21:17 ID:y0wTEagk
>>154
beginners(?)がbegginersになっているのは何か意味が？
beginners(?)がbegginersになっているのは何か意味が？
159 ：茶文字 ◆xELvisFU ：02/04/18 21:32 ID:JS4ZjtYj
160 ：Name_Not_Found：02/04/18 21:42 ID:tkUsmvON
ソースが命！ なので view-source: 付きリンクがあると、とか。
それなりに自衛はしてるけど、ブラクラは怖い……
それなりに自衛はしてるけど、ブラクラは怖い……
>>156
>何がどういう目的でうｐされているのか把握したいと思っているので
それだと確かに厳しいですね。
需要はあると言えばあるし、ないといえばないです。
ので、用途の方はそちらの方針に基くもので良いかと。
>何がどういう目的でうｐされているのか把握したいと思っているので
それだと確かに厳しいですね。
需要はあると言えばあるし、ないといえばないです。
ので、用途の方はそちらの方針に基くもので良いかと。
152の方法で作ってみてかなりイイ！と思っていたんですが、
display: inline
がN4に対応してないのでレイアウトで死んでしまいました。
ゲーム製作サイトである以上テキストブラウザとかは無視できてもN4だけは無視できない…。
とりあえず、Tableが一番良さげなのでこれで様子見ます。
display: inline
がN4に対応してないのでレイアウトで死んでしまいました。
ゲーム製作サイトである以上テキストブラウザとかは無視できてもN4だけは無視できない…。
とりあえず、Tableが一番良さげなのでこれで様子見ます。
163 ：135：02/04/18 22:22 ID:mjUoN0KA
164 ：1：02/04/18 22:22 ID:WfpwsK96
>>159
> 使える.net規約に反するファイルのアップロードはお断りします。
> 具体的には、静的表現を含む文章（以下略）
動的表現じゃないとダメですか？
>>162
@importとかmedia="screen,print"とかを使って
N4にCSS読み込ませない方法じゃダメですか？
> 使える.net規約に反するファイルのアップロードはお断りします。
> 具体的には、静的表現を含む文章（以下略）
動的表現じゃないとダメですか？
>>162
@importとかmedia="screen,print"とかを使って
N4にCSS読み込ませない方法じゃダメですか？
165 ：135：02/04/18 22:26 ID:mjUoN0KA
>>162
それだと、リスト部分がN4だと縦表示になりますよね？
ゲームソフトの販促用サイトなんでN4無視すると売り上げ下がる可能性もあるんです。
まぁ、縦表示になる以外はN4でもなんとかかっこよく見せることが出来るんですけどね。
それだと、リスト部分がN4だと縦表示になりますよね？
ゲームソフトの販促用サイトなんでN4無視すると売り上げ下がる可能性もあるんです。
まぁ、縦表示になる以外はN4でもなんとかかっこよく見せることが出来るんですけどね。
166 ：135：02/04/18 22:35 ID:mjUoN0KA
もしかしたらJSSならなんとか出来るかも。
けど、N4では切ってる人多いって聞くからなあ。
けど、N4では切ってる人多いって聞くからなあ。
167 ：茶文字 ◆xELvisFU ：02/04/18 22:47 ID:JS4ZjtYj
168 ：Name_Not_Found：02/04/18 23:05 ID:k4Bk7Ad8
169 ：1：02/04/18 23:12 ID:UqJ4hxV3
>>165
Strict宣言しつつ、NN4で格好良く見せるのって難しくないですか？
そこまでNN4にも気を使うなら、いっそTransitonalの方がいいのでは？
あー、とはいえ、Transitionalでも、不思議マークアップを併用しないと、
NN4でヴィジュアル的に格好良く見せるのって難しいか。
Strict宣言しつつ、NN4で格好良く見せるのって難しくないですか？
そこまでNN4にも気を使うなら、いっそTransitonalの方がいいのでは？
あー、とはいえ、Transitionalでも、不思議マークアップを併用しないと、
NN4でヴィジュアル的に格好良く見せるのって難しいか。
170 ：135：02/04/18 23:17 ID:mjUoN0KA
>>168
テキストブラウザやN4ではこうなります。
必須環境
CPU
PentiumIII
メモリ
64MB
HDD
未定
（略～）
推奨環境
CPU
PentiumIII
メモリ
64MB
HDD
未定
（略～）
こんなページ魅力あります？
私ならこんな告知するゲームはゲーム内容良くても興味持たないかも。
テキストブラウザやN4ではこうなります。
必須環境
CPU
PentiumIII
メモリ
64MB
HDD
未定
（略～）
推奨環境
CPU
PentiumIII
メモリ
64MB
HDD
未定
（略～）
こんなページ魅力あります？
私ならこんな告知するゲームはゲーム内容良くても興味持たないかも。
171 ：Name_Not_Found：02/04/18 23:20 ID:FYGZUE7a
>>170
読めるのが何より重要ですから。
読めるのが何より重要ですから。
172 ：Name_Not_Found：02/04/18 23:20 ID:k4Bk7Ad8
173 ：Name_Not_Found：02/04/18 23:26 ID:uYERfq6k
174 ：Name_Not_Found：02/04/18 23:28 ID:k4Bk7Ad8
音声ブラウザの人は大変ですは、summaryつけとけば一応大丈夫だと思。
175 ：135：02/04/18 23:29 ID:mjUoN0KA
176 ：Name_Not_Found：02/04/18 23:30 ID:FYGZUE7a
CAPTIONは使わないの？
177 ：Name_Not_Found：02/04/18 23:30 ID:k4Bk7Ad8
でも、"動作環境"をcaptionにまわしてsummaryはもっと具体的にしたほうがいいと思いますね。
あ、ダブった
179 ：135：02/04/18 23:32 ID:mjUoN0KA
>>163ファイル末尾の table だと、音声ブラウザでも170のように読まれる（はず）から問題はないんですが……理想を追求する方の意見を聞きたくて
180 ：Name_Not_Found：02/04/18 23:34 ID:FYGZUE7a
>>179
W3C的には線形に展開して意味が通ればOK。
W3C的には線形に展開して意味が通ればOK。
182 ：Name_Not_Found：02/04/18 23:37 ID:0tKoertu
>>170
特定 UA の表示結果を非常に気にしなければいけないなら
Strict は止めた方がいいと思う。
もともと表示結果はブラウザにお任せの文書型なんだから。
# もっと言えば HTML 自体がそういうファイル形式なんだが。
特定 UA の表示結果を非常に気にしなければいけないなら
Strict は止めた方がいいと思う。
もともと表示結果はブラウザにお任せの文書型なんだから。
# もっと言えば HTML 自体がそういうファイル形式なんだが。
>>181
＞クライアント / 上司の意向ですか？
いえ、独立第一作目ですね。販売は別会社ですが…
>>182
それは痛いほどわかっているんですけど、XHTML1.1以降はTranstionalが完全に消えましたからね。将来性も考えると…
＞クライアント / 上司の意向ですか？
いえ、独立第一作目ですね。販売は別会社ですが…
>>182
それは痛いほどわかっているんですけど、XHTML1.1以降はTranstionalが完全に消えましたからね。将来性も考えると…
現在の鯖(UNIX)をASP使えるWindows鯖に変えればXML+XSLTでMSのように出来るんですが…
さくらをやめてそれ以上の鯖があるかわからないし…
さくらをやめてそれ以上の鯖があるかわからないし…
<table xml:lang="ja" summary="動作環境">
<caption>動作環境<caption>
<tr xml:lang="ja"><th title="空白"></th><th>必須環境</th><th>推奨環境</th></tr>
<tr xml:lang="en"><td>CPU</td><td>Pentium3 500MHz</td><td>Pentium4 1.5GHz</td></tr>
<tr xml:lang="en"><td xml:lang="ja">メモリ</td> <td>64MB</td><td>256MB</td></tr>
<tr xml:lang="ja"><td xml:lang="en">HDD</td><td>未定</td><td title="空白"></td></tr>
<tr xml:lang="en"><td xml:lang="ja">ビデオカード</td><td>GeForce2MX</td><td>GeForce3</td></tr>
<tr xml:lang="en"><td xml:lang="ja">ディスプレイ</td><td>VGA HighColor</td><td></td></tr>
<tr xml:lang="ja"><td>ジョイパッド</td><td>4ボタン</td><td>8ボタン以上</td></tr>
</table>
これくらいかなあ。
<caption>動作環境<caption>
<tr xml:lang="ja"><th title="空白"></th><th>必須環境</th><th>推奨環境</th></tr>
<tr xml:lang="en"><td>CPU</td><td>Pentium3 500MHz</td><td>Pentium4 1.5GHz</td></tr>
<tr xml:lang="en"><td xml:lang="ja">メモリ</td> <td>64MB</td><td>256MB</td></tr>
<tr xml:lang="ja"><td xml:lang="en">HDD</td><td>未定</td><td title="空白"></td></tr>
<tr xml:lang="en"><td xml:lang="ja">ビデオカード</td><td>GeForce2MX</td><td>GeForce3</td></tr>
<tr xml:lang="en"><td xml:lang="ja">ディスプレイ</td><td>VGA HighColor</td><td></td></tr>
<tr xml:lang="ja"><td>ジョイパッド</td><td>4ボタン</td><td>8ボタン以上</td></tr>
</table>
これくらいかなあ。
186 ：Name_Not_Found：02/04/19 00:04 ID:R+KDYGAk
188 ：Name_Not_Found：02/04/19 00:12 ID:sEVYqgCD
135氏
役に立つかはわからんけど、XHTML1.1 で金取っているサイトっって言うと
語弊があるか。アマゾンアソシエイトを利用した、書籍紹介サイト。
http://bookshelves.tripod.co.jp/index.html
煮詰まっているときは余所様のサイト研究ってことで。
ﾏﾀｰﾘ行きましょう。
役に立つかはわからんけど、XHTML1.1 で金取っているサイトっって言うと
語弊があるか。アマゾンアソシエイトを利用した、書籍紹介サイト。
http://bookshelves.tripod.co.jp/index.html
煮詰まっているときは余所様のサイト研究ってことで。
ﾏﾀｰﾘ行きましょう。
↑重いかも
>>188
なんか pre を多用しているようなサイトですね。
preの使い方間違ってるような…主にソースコードに使うのが pre のはず
つか、 pre 使えばTableと同等にレイアウト出来る。Table以上に不適切だけど…
なんか pre を多用しているようなサイトですね。
preの使い方間違ってるような…主にソースコードに使うのが pre のはず
つか、 pre 使えばTableと同等にレイアウト出来る。Table以上に不適切だけど…
191 ：Name_Not_Found：02/04/19 00:27 ID:3PRgyH+h
>>190
レイアウト目的にpre使ってる？
レイアウト目的にpre使ってる？
>>190
レイアウト目的じゃないけど本来は別の方法があるんじゃない？
レイアウト目的じゃないけど本来は別の方法があるんじゃない？
194 ：Name_Not_Found：02/04/19 00:52 ID:3PRgyH+h
>>193
具体的な場所を教えてくれ。
具体的な場所を教えてくれ。
195 ：Name_Not_Found：02/04/19 02:28 ID:R+KDYGAk
>>194
遅レスごめん、ニュース見てた。
たとえば、
http://bookshelves.tripod.co.jp/Html/computer.html
のdl,dt,dd の使い方見てると、135氏のソースと似ているなぁと。
んで、煮詰まり気味(?)の氏の参考になってくれればと思った次第
だったんだが、意味不明だったね。申し訳ない。
遅レスごめん、ニュース見てた。
たとえば、
http://bookshelves.tripod.co.jp/Html/computer.html
のdl,dt,dd の使い方見てると、135氏のソースと似ているなぁと。
んで、煮詰まり気味(?)の氏の参考になってくれればと思った次第
だったんだが、意味不明だったね。申し訳ない。
＞135氏
>>195 に同意で、漏れも table の方が良いと思っている。
それは、>>173でも書いたとおりです。
つーか、アレで table 使わなかったら何時使うのよ？ってカンジ。
十分すぎるほど table に値する内容だし、複雑なリストで記述を
をミスったりするより、ずっと賢明だと思います。
あぁ、ダメだ。日本語メタメタだ。寝ます。sage
>>195 に同意で、漏れも table の方が良いと思っている。
それは、>>173でも書いたとおりです。
つーか、アレで table 使わなかったら何時使うのよ？ってカンジ。
十分すぎるほど table に値する内容だし、複雑なリストで記述を
をミスったりするより、ずっと賢明だと思います。
あぁ、ダメだ。日本語メタメタだ。寝ます。sage
>>144
> 最上位は<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">でUTF-8のマルチランゲージです。
いや、それはいいんだが、html 要素が xml:lang="en" ってことは英語がメインなの?
そうなら >>135 で構わないけど、英語メインで日本語補助なんてことなくないか?
> 最上位は<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">でUTF-8のマルチランゲージです。
いや、それはいいんだが、html 要素が xml:lang="en" ってことは英語がメインなの?
そうなら >>135 で構わないけど、英語メインで日本語補助なんてことなくないか?
>>197
>つーか、アレで table 使わなかったら何時使うのよ？
そうですねえ。いくら空白が入っているからと言っても表ですからね。
>>198
>英語メインで日本語補助
ん？そうですが？英語と日本語で英語の使用度が高ければそちらが適切なんじゃない？別に日本人しか見れないページにしてませんし。動作環境も日本語・英語用意しますから。
>つーか、アレで table 使わなかったら何時使うのよ？
そうですねえ。いくら空白が入っているからと言っても表ですからね。
>>198
>英語メインで日本語補助
ん？そうですが？英語と日本語で英語の使用度が高ければそちらが適切なんじゃない？別に日本人しか見れないページにしてませんし。動作環境も日本語・英語用意しますから。
Strictだと
<table>
<caption>参加者リスト</caption>
<tr><th>名前</th><th>年齢</th><th>性別</th>
<tr><td>山田 太郎</td><td>10</td><td>男</td>
<tr><td>山田 花子</td><td>9</td><td>女</td>
のような完璧な表しか駄目なのかな？
損益計算書と貸借対照表（表ですよね）とかにもTableは不適切なんだろうか？
<table>
<caption>参加者リスト</caption>
<tr><th>名前</th><th>年齢</th><th>性別</th>
<tr><td>山田 太郎</td><td>10</td><td>男</td>
<tr><td>山田 花子</td><td>9</td><td>女</td>
のような完璧な表しか駄目なのかな？
損益計算書と貸借対照表（表ですよね）とかにもTableは不適切なんだろうか？
<th abbr="利益">売上総利益（損失）</th>
<tr><th abbr="必須CPUと推奨CPU">CPU</th><td abbr="必須CPUはPentium3の500MHzです。">PentiumIII 500MHz</td><td abbr="推奨CPUはPentium4の1.5GHzです。">Pentium4 1.5GHz</td></tr>
こうしたら音声ブラウザでも意味が通るかな？
貸借対照表とかの複雑な表でもこうしないと音声ブラウザじゃわからないかも。
<tr><th abbr="必須CPUと推奨CPU">CPU</th><td abbr="必須CPUはPentium3の500MHzです。">PentiumIII 500MHz</td><td abbr="推奨CPUはPentium4の1.5GHzです。">Pentium4 1.5GHz</td></tr>
こうしたら音声ブラウザでも意味が通るかな？
貸借対照表とかの複雑な表でもこうしないと音声ブラウザじゃわからないかも。
>>201の1行目は無視してください。
しかし、音声対応って意外と面倒ですね。
しかし、音声対応って意外と面倒ですね。
あ！表のことまったくわかってなかった。
>>201のようなアフォなことせずとも163の表では
「CPU 必須環境 Pentium3 500MHz」、「CPU 推奨環境 Pentium4 1.5GHz」と読んでくれるんですね。
>>201のようなアフォなことせずとも163の表では
「CPU 必須環境 Pentium3 500MHz」、「CPU 推奨環境 Pentium4 1.5GHz」と読んでくれるんですね。
204 ：Name_Not_Found：02/04/19 09:04 ID:SZmlg0ZG
>>200
表の定義って何よ？ ってことだわな。新辞林さんはこう言ってる。
http://dic.yahoo.co.jp/bin/docsearch?p=snj26404224&check=c
あれで table が不適切だと言う人って
なんか dl ばっかり要素の意味を拡大解釈してて
table についてはやけに狭義で厳密なような気がする。
# Table of Contents って <table> で書かないといけないのかな？(w
表の定義って何よ？ ってことだわな。新辞林さんはこう言ってる。
http://dic.yahoo.co.jp/bin/docsearch?p=snj26404224&check=c
あれで table が不適切だと言う人って
なんか dl ばっかり要素の意味を拡大解釈してて
table についてはやけに狭義で厳密なような気がする。
# Table of Contents って <table> で書かないといけないのかな？(w
scope属性、id属性、headers属性、axis属性を使えばもっといいかも。
207 ：Name_Not_Found：02/04/19 09:36 ID:SZmlg0ZG
>>206
thead と tbody をつけてないのは、何か意図があるの？
thead と tbody をつけてないのは、何か意図があるの？
208 ：Name_Not_Found：02/04/19 09:37 ID:HGw4VdRb
>>204
従来の表は主に「見た目」を指しているので、見た目と意味付けを分離した
HTML では、「表はスタイルシートで」という主張が出るのはある程度必然かと。
俺の場合、情報の標題が１つのものは ul か ol、標題が複数あるが縦軸または横軸１本になるものは dl、
標題が格子状に並んでいるものはテーブルという風にして使い分けている。（つもり）
>Table of Contents って <table> で書かないといけないのかな？(w
目次って意味での「Table of Contents」ならリスト形式(dl か ul か ol かは
物による)にするのが HTML では正解だと思う。
（Hyperlink によりページの表示はいらなくなるので）
因みに、「予定”表”」「番組”表”」「タイム”テーブル”」の類であれば、
俺は文句なくテーブルにする。（ただし、その”予定表”をカレンダー風の
見た目にするのはスタイルシートの役割な。）
従来の表は主に「見た目」を指しているので、見た目と意味付けを分離した
HTML では、「表はスタイルシートで」という主張が出るのはある程度必然かと。
俺の場合、情報の標題が１つのものは ul か ol、標題が複数あるが縦軸または横軸１本になるものは dl、
標題が格子状に並んでいるものはテーブルという風にして使い分けている。（つもり）
>Table of Contents って <table> で書かないといけないのかな？(w
目次って意味での「Table of Contents」ならリスト形式(dl か ul か ol かは
物による)にするのが HTML では正解だと思う。
（Hyperlink によりページの表示はいらなくなるので）
因みに、「予定”表”」「番組”表”」「タイム”テーブル”」の類であれば、
俺は文句なくテーブルにする。（ただし、その”予定表”をカレンダー風の
見た目にするのはスタイルシートの役割な。）
>>207
ただの入れ忘れ
ただの入れ忘れ
>>208
ってことは、俺の場合はテーブルが良いわけね。
音声で「CPU 必須環境 Pentium3 500MHz」、「CPU 推奨環境 Pentium4 1.5GHz」と読ませるにはそれしかないし。
ってことは、俺の場合はテーブルが良いわけね。
音声で「CPU 必須環境 Pentium3 500MHz」、「CPU 推奨環境 Pentium4 1.5GHz」と読ませるにはそれしかないし。
211 ：Name_Not_Found：02/04/19 10:05 ID:mOsbaLAf
tbodyは初期のNN4を撃墜するって聞いたけど。
>>211
それどころか今の最新N4でも撃墜するみたい。辞典あってよかった…。
それどころか今の最新N4でも撃墜するみたい。辞典あってよかった…。
213 ：Name_Not_Found：02/04/19 10:21 ID:SZmlg0ZG
>>211-212
撃墜の詳細を知りたいんだが、参考 URL ご存知ならきぼんぬ。
撃墜の詳細を知りたいんだが、参考 URL ご存知ならきぼんぬ。
215 ：Name_Not_Found：02/04/19 10:35 ID:EQbSHRTj
ただの未対応ではなくて、スタイル指定すると強制終了する。
labelとかと同様に。
labelとかと同様に。
>>214
別に CSS との組み合わせによって落ちたりはしないのね。ひと安心。ありが㌧。
別に CSS との組み合わせによって落ちたりはしないのね。ひと安心。ありが㌧。
>>215
おぁ、やっぱ落ちるのか...(涙)
おぁ、やっぱ落ちるのか...(涙)
>>216
落ちるみたいよ。スタイル指定は別でやったほうがよさそう。
落ちるみたいよ。スタイル指定は別でやったほうがよさそう。
219 ：Name_Not_Found：02/04/19 11:03 ID:HGw4VdRb
>>213-218
スレ違い。
スレ違い。
>>199
おお、本当に英語メインなのね。疑ってスマソ。
>>206
summary="動作環境" は…できればもうちょっと詳しい方がベターな気がする。
アクセシビリティ的な観点から折角 summary を書いてるんだろうから、
それだったら caption そのままってのは味気ない(冗長)んじゃないかな。
<abbr title="3">III</abbr> はちょっと違う気がする(略語なのか?)。
単に <span title="3">III</span> でいいんじゃない?
(勿論 Ⅲ でもいいけど)
おお、本当に英語メインなのね。疑ってスマソ。
>>206
summary="動作環境" は…できればもうちょっと詳しい方がベターな気がする。
アクセシビリティ的な観点から折角 summary を書いてるんだろうから、
それだったら caption そのままってのは味気ない(冗長)んじゃないかな。
<abbr title="3">III</abbr> はちょっと違う気がする(略語なのか?)。
単に <span title="3">III</span> でいいんじゃない?
(勿論 Ⅲ でもいいけど)
221 ：Name_Not_Found：02/04/19 17:07 ID:R+KDYGAk
>>204
テーブルってC言語のgotoみたいなものだと思ってる、オレは。
リスト(while)や定義(for)の代わりにも使えるけど、
リストや定義で間にあうならそれ使えと。
んで、テーブル使ったほうがすっきりする(>>208後半)なら使えと。
ただ、135が最初からテーブル使いたそうだったんで>>195って書いたけど、
今でもアレは定義だと思ってたりする。
テーブルってC言語のgotoみたいなものだと思ってる、オレは。
リスト(while)や定義(for)の代わりにも使えるけど、
リストや定義で間にあうならそれ使えと。
んで、テーブル使ったほうがすっきりする(>>208後半)なら使えと。
ただ、135が最初からテーブル使いたそうだったんで>>195って書いたけど、
今でもアレは定義だと思ってたりする。
222 ：Name_Not_Found：02/04/19 17:47 ID:SZmlg0ZG
225 ：Name_Not_Found：02/04/19 19:49 ID:R+KDYGAk
>135 の動作環境は「一覧表」じゃないの？
なんかうまく言えないけど。
動作/推奨環境という項目があって、その中でメモリは64M以上という定義がある。
>>200の場合は名前は山田太郎という定義じゃない。
この辺のコトバの感覚は人それぞれだけど。
それに、神崎さんのトコロのdl解説例も表だと言えば表になるんで。
なんかうまく言えないけど。
動作/推奨環境という項目があって、その中でメモリは64M以上という定義がある。
>>200の場合は名前は山田太郎という定義じゃない。
この辺のコトバの感覚は人それぞれだけど。
それに、神崎さんのトコロのdl解説例も表だと言えば表になるんで。
226 ：225=223=221：02/04/19 19:52 ID:R+KDYGAk
>じゃあ、「年齢」がいらなくなって「性別」だけになったら、 dl になる？
これは普通に意味が分からん。茶ぷろだ使えなかったんで張るけど、どれ？
--------
<h1>参加者リスト</h1>
<ul>
<li>
<dl>
<dt>名前</dt>
<dd>山田 太郎</dd>
<dt>年齢</dt>
<dd>10</dd>
</dl>
</li>
</ul>
--------
<h1>参加者リスト</h1>
<ul>
<li>山田 太郎
<dl>
<dt>年齢</dt>
<dd>10</dd>
</dl>
</li>
</ul>
--------
<h1>参加者リスト</h1>
<dl>
<dt>山田 太郎</dt>
<dd>10</dd>
</dl>
これは普通に意味が分からん。茶ぷろだ使えなかったんで張るけど、どれ？
--------
<h1>参加者リスト</h1>
<ul>
<li>
<dl>
<dt>名前</dt>
<dd>山田 太郎</dd>
<dt>年齢</dt>
<dd>10</dd>
</dl>
</li>
</ul>
--------
<h1>参加者リスト</h1>
<ul>
<li>山田 太郎
<dl>
<dt>年齢</dt>
<dd>10</dd>
</dl>
</li>
</ul>
--------
<h1>参加者リスト</h1>
<dl>
<dt>山田 太郎</dt>
<dd>10</dd>
</dl>
>>225-226
そういうことか。感覚なんだなあ。
漏れにとっては動作環境と参加者リストってデータ構造が一緒だったんだよ。
メモリという項目が動作環境/推奨環境というデータを持っている。
山田太郎という項目が年齢/性別ってデータを持っている。
だから一方が「表」で他方が「定義」というのがかなり意味不明だったんだ。
224 では 226 の 3番目になるの？ と聞きたかった。
でも 225 で定義とする考え方には納得できた。ありがとう。
そういうことか。感覚なんだなあ。
漏れにとっては動作環境と参加者リストってデータ構造が一緒だったんだよ。
メモリという項目が動作環境/推奨環境というデータを持っている。
山田太郎という項目が年齢/性別ってデータを持っている。
だから一方が「表」で他方が「定義」というのがかなり意味不明だったんだ。
224 では 226 の 3番目になるの？ と聞きたかった。
でも 225 で定義とする考え方には納得できた。ありがとう。
>>221
C#やC++ではgotoは使いませんね。つか、gotoでしか解決できないことはないんですけどね。goto使うとスパゲッティコードになるし。
でも、これとテーブルはちょっと違う気がする。
テーブルでやったはおうが良い場合もあると思う。
好んで使ってるわけじゃないです。他に回避法があればそれに行きたいほどですね。
C#やC++ではgotoは使いませんね。つか、gotoでしか解決できないことはないんですけどね。goto使うとスパゲッティコードになるし。
でも、これとテーブルはちょっと違う気がする。
テーブルでやったはおうが良い場合もあると思う。
好んで使ってるわけじゃないです。他に回避法があればそれに行きたいほどですね。
229 ：Name_Not_Found：02/04/20 02:07 ID:tYN56+KO
全く関係ない話でスマンのだが、昨日自鯖構築の勉強中に一眠りしてたら
「StrictなXHTML/HTMLで書かれたサイトのみ対象の無良鯖を公開する」
という夢を見たよ（w
ﾁｮﾄいいなと思ったのでこれを目標に鯖立て・運用できるように勉強することにした（w
いや、全く関係ない話でスマソ・・・sage
「StrictなXHTML/HTMLで書かれたサイトのみ対象の無良鯖を公開する」
という夢を見たよ（w
ﾁｮﾄいいなと思ったのでこれを目標に鯖立て・運用できるように勉強することにした（w
いや、全く関係ない話でスマソ・・・sage
230 ：Name_Not_Found：02/04/20 02:09 ID:32K26V1m
>>229
どこかで聞いた覚えがある鯖だな(w
どこかで聞いた覚えがある鯖だな(w
231 ：Name_Not_Found：02/04/20 02:14 ID:rVla48YQ
遲レスだけど、スレの前半で小説をStrictにマークアップする話が出てたけど、読
者に微妙な雰囲気みたいなものを伝えようとする時点で、それはHTMLの領域じゃな
いんだと思う。
Strict HTMLってのは「これは大見出し！」「これは段落！」みたいに文章の意味
を明示するもので、微妙な雰囲気みたいなのを何気なく出すのには全く向かないん
じゃないかと。
者に微妙な雰囲気みたいなものを伝えようとする時点で、それはHTMLの領域じゃな
いんだと思う。
Strict HTMLってのは「これは大見出し！」「これは段落！」みたいに文章の意味
を明示するもので、微妙な雰囲気みたいなのを何気なく出すのには全く向かないん
じゃないかと。
232 ：Name_Not_Found：02/04/20 08:21 ID:FdUk4/fL
段落分けは、別ファイルにしちゃう
233 ：Name_Not_Found：02/04/20 10:45 ID:5Jy5nwvU
<h1>お勧めのリンゴ紹介</h1>
<h2>蜜リンゴ</h2>
<h3>青森産</h3><ul>
<li><h4>AAAリンゴ</h4><ul>
<li>発売元<ul>
<li><a href="http://">http://</a></li>
</ul></li>
</ul>
とするか、
<h1>お勧めのリンゴ紹介</h1>
<h2>蜜リンゴ</h2>
<h3>青森産</h3>
<h4>AAAリンゴ</h4><ul>
<li>発売元<ul>
<li><a href="http://">http://</a></li>
</ul></li>
</ul>
のどちらがいいですか？
<h2>蜜リンゴ</h2>
<h3>青森産</h3><ul>
<li><h4>AAAリンゴ</h4><ul>
<li>発売元<ul>
<li><a href="http://">http://</a></li>
</ul></li>
</ul>
とするか、
<h1>お勧めのリンゴ紹介</h1>
<h2>蜜リンゴ</h2>
<h3>青森産</h3>
<h4>AAAリンゴ</h4><ul>
<li>発売元<ul>
<li><a href="http://">http://</a></li>
</ul></li>
</ul>
のどちらがいいですか？
234 ：Name_Not_Found：02/04/20 10:51 ID:i7UzJu66
235 ：Name_Not_Found：02/04/20 11:07 ID:RM4NR5A1
>>233
hnってそのように使っちゃいけないような…
hnってそのように使っちゃいけないような…
236 ：Name_Not_Found：02/04/20 11:42 ID:/E4ann8o
>>233
かなり根本的に微妙な気がするが、どちらかと言えば後者。
で、ul よりも dl の方がいいと思う。
h1-h4 は「見出し」なんだけど、「見出し」の意味解ってる?
途中を省略しただけかな。
かなり根本的に微妙な気がするが、どちらかと言えば後者。
で、ul よりも dl の方がいいと思う。
h1-h4 は「見出し」なんだけど、「見出し」の意味解ってる?
途中を省略しただけかな。
>233
話が逸れる上に、異論も出そうな話なので、参考程度にとどめて欲しいんだが、
<li>
発売元
<ul><li><a href="http://">http://</a></li></ul>
</li>
最初の li 内において、inline レベルのテキスト（発売元）と
block レベルの ul が混在する、こう言う書き方はあまり好ましくない。
AAAリンゴが h4 で markup されるなら、是非発売元も h5 で markup して欲しい。
勿論、DTD 上では li の子要素は (( %inline; ) | ( %block; ))* なので
上記 markup でも<strong>全く問題ない</strong>んだが、
出来れば (( %inline; )+ | ( %block; )+ ) に合致するような書き方を心がけて欲しい。
＃これは div,dd,tr,td 辺りでも同じ
話が逸れる上に、異論も出そうな話なので、参考程度にとどめて欲しいんだが、
<li>
発売元
<ul><li><a href="http://">http://</a></li></ul>
</li>
最初の li 内において、inline レベルのテキスト（発売元）と
block レベルの ul が混在する、こう言う書き方はあまり好ましくない。
AAAリンゴが h4 で markup されるなら、是非発売元も h5 で markup して欲しい。
勿論、DTD 上では li の子要素は (( %inline; ) | ( %block; ))* なので
上記 markup でも<strong>全く問題ない</strong>んだが、
出来れば (( %inline; )+ | ( %block; )+ ) に合致するような書き方を心がけて欲しい。
＃これは div,dd,tr,td 辺りでも同じ
238 ：Name_Not_Found：02/04/20 15:13 ID:I+AJ2bMY
俺も hn と dl で迷う時がある。見出しってなんだろうとか
dt って dd の見出しじゃないのか？ とか思い始めるときりがない。
例えばタグ辞典やCSSリファレンスみたいな文書では、次の２つのどっちがよりよい？
-----------------------------
<hn>タグ</hn>
<p>説明...</p>
-----------------------------
<dl>
<dt>タグ</dt>
<dd><p>説明...</p></dd>
</dl>
-----------------------------
hn を使う場合、タグを「リスト」「表」のように分類して記述しようとすると、
分類内の小分類の有無によって
あるタグは h3 だけど別なタグは h4、という場面が出てきて、なんか気持ち悪い。
一方 dl を使うと、個々の説明(dd)中の一節に見出しが必要になった場合に
hn を使うと見出し階層的にそれはおかしいんじゃないのか？という状態になる気がする。
どうするのがいいんだろう？
>>237
tr?
dt って dd の見出しじゃないのか？ とか思い始めるときりがない。
例えばタグ辞典やCSSリファレンスみたいな文書では、次の２つのどっちがよりよい？
-----------------------------
<hn>タグ</hn>
<p>説明...</p>
-----------------------------
<dl>
<dt>タグ</dt>
<dd><p>説明...</p></dd>
</dl>
-----------------------------
hn を使う場合、タグを「リスト」「表」のように分類して記述しようとすると、
分類内の小分類の有無によって
あるタグは h3 だけど別なタグは h4、という場面が出てきて、なんか気持ち悪い。
一方 dl を使うと、個々の説明(dd)中の一節に見出しが必要になった場合に
hn を使うと見出し階層的にそれはおかしいんじゃないのか？という状態になる気がする。
どうするのがいいんだろう？
>>237
tr?
239 ：茶文字 ◆xELvisFU ：02/04/20 15:24 ID:VkAOnfjk
>>238
<h1>タグ辞典</h1>
<h2>ブロック要素</h2>
<p>ブロック要素の説明</p>
<div class="reference">
<h1>p</h1>
<p>段落をマークアップします。</p>
<h2>p要素はインライン要素しか内包できません</h2>
<p>pの中にブロック要素をネストすることはできないぜﾍﾞｲﾍﾞ。</p>
</div>
こういうのってﾏｽﾞｰ？
<h1>タグ辞典</h1>
<h2>ブロック要素</h2>
<p>ブロック要素の説明</p>
<div class="reference">
<h1>p</h1>
<p>段落をマークアップします。</p>
<h2>p要素はインライン要素しか内包できません</h2>
<p>pの中にブロック要素をネストすることはできないぜﾍﾞｲﾍﾞ。</p>
</div>
こういうのってﾏｽﾞｰ？
死ぬほど悩んだ（ホームページリーダーで読んだ）結果、tableが最適だと判断しました。それで、数ヶ月tableで様子見することにしました。
その間、顧客からのメールでtableが上手く表示されない、聞こえない、という意見があれば直そうと思います。HTMLは日々進化してるので、いちいち最初から完璧を求めても苦しむだけですしね。
ありがとうございました。
その間、顧客からのメールでtableが上手く表示されない、聞こえない、という意見があれば直そうと思います。HTMLは日々進化してるので、いちいち最初から完璧を求めても苦しむだけですしね。
ありがとうございました。
242 ：Name_Not_Found：02/04/20 16:25 ID:rVla48YQ
>>238
たしかに。どっちでもいい気がして、どっちにするべきか。
たしかに。どっちでもいい気がして、どっちにするべきか。
>>238
>分類内の小分類の有無によって
>あるタグは h3 だけど別なタグは h4、という場面が出てきて、なんか気持ち悪い。
確かに気持ち悪いが、「小分類の有無」によって階層が異なってしまうデータを
markup するのだから仕方のない話かと思う。
後は、それがリストか否か、という点で dl を使うかどうかを俺は決めている。
例えば、見出しだけ抜き出した物を箇条書きしたときに ul or ol での
表記が相応しければ hn + p という方向で (飽くまでデータに寄るので、最後には
個別判断になるが)。
>分類内の小分類の有無によって
>あるタグは h3 だけど別なタグは h4、という場面が出てきて、なんか気持ち悪い。
確かに気持ち悪いが、「小分類の有無」によって階層が異なってしまうデータを
markup するのだから仕方のない話かと思う。
後は、それがリストか否か、という点で dl を使うかどうかを俺は決めている。
例えば、見出しだけ抜き出した物を箇条書きしたときに ul or ol での
表記が相応しければ hn + p という方向で (飽くまでデータに寄るので、最後には
個別判断になるが)。
245 ：Name_Not_Found：02/04/20 21:20 ID:CY4lq/4F
>>237
それ、すみけんさんも書いてるんだよね。
本当は解ってる人間がやる分には問題ないと思うんだけど。
(初心者はそのように心掛けた方が良い、というのには同意だが)
ディレクトリリストなんかではそういうマークアップにするのが一般的だし、
インラインとブロックの混在が認められないというなら
XHTML 2.0 で許されるらしい段落内のリストなんかも駄目ってことだろうし。
それ、すみけんさんも書いてるんだよね。
本当は解ってる人間がやる分には問題ないと思うんだけど。
(初心者はそのように心掛けた方が良い、というのには同意だが)
ディレクトリリストなんかではそういうマークアップにするのが一般的だし、
インラインとブロックの混在が認められないというなら
XHTML 2.0 で許されるらしい段落内のリストなんかも駄目ってことだろうし。
246 ：1：02/04/20 22:22 ID:g/GJjRp6
>>245
>それ、すみけんさんも書いてるんだよね。
そうっすね。氏は、これを平成１０年の段階で本にしている、という点が
すごいな、と。
>本当は解ってる人間がやる分には問題ないと思うんだけど。
>(初心者はそのように心掛けた方が良い、というのには同意だが)
なので、飽くまで、参考程度に。
理由があって、自然にインラインとブロックレベルの要素が
混在しているところを、無理やりインライン要素を div でくくれ、とまでは
いう気は有りません、って事で。
>XHTML 2.0 で許されるらしい段落内のリストなんかも駄目ってことだろうし。
現段階で XHTML の構造に関して論議しても詮無い事なんだが、
<section>
<h>HTML 4.01の種類</h>
<p>
<l>HTML 4.01 には</l>
<ol>
<li>strict</li>
<li>transitional</li>
<li>frameset</li>
</ol>
<l>の三種類があります。</l>
</p>
</section>
こんな風になるのかなぁ、と漠然と思ってます。
参考: http://www.w3.org/2001/09/21-orf/xhtml-family/slide24-0.html
>それ、すみけんさんも書いてるんだよね。
そうっすね。氏は、これを平成１０年の段階で本にしている、という点が
すごいな、と。
>本当は解ってる人間がやる分には問題ないと思うんだけど。
>(初心者はそのように心掛けた方が良い、というのには同意だが)
なので、飽くまで、参考程度に。
理由があって、自然にインラインとブロックレベルの要素が
混在しているところを、無理やりインライン要素を div でくくれ、とまでは
いう気は有りません、って事で。
>XHTML 2.0 で許されるらしい段落内のリストなんかも駄目ってことだろうし。
現段階で XHTML の構造に関して論議しても詮無い事なんだが、
<section>
<h>HTML 4.01の種類</h>
<p>
<l>HTML 4.01 には</l>
<ol>
<li>strict</li>
<li>transitional</li>
<li>frameset</li>
</ol>
<l>の三種類があります。</l>
</p>
</section>
こんな風になるのかなぁ、と漠然と思ってます。
参考: http://www.w3.org/2001/09/21-orf/xhtml-family/slide24-0.html
248 ：Name_Not_Found：02/04/20 23:44 ID:CY4lq/4F
>>246
<div>
今日の出来事
<p>色んなことがありました。</p>
</div>
例えばこういうのは余り好ましくない。
dl や h1 でマークしろって言うのではなく、データとして扱いにくいから。
要するに、上のような状態では「今日の出来事」という部分だけを
要素として抽出することができないんだよね
(こういうのを匿名ブロックと言う)。
↓ちょっと違うけどこれが似ている感じ。
http://pc.2ch.net/test/read.cgi/hp/984950028/438-439n
ただし、
<div>
よくいくところは
<ul>
<li>2ch</li>
<li>W3C</li>
</ul>
などです。
</div>
みたいなケースでは、「よくいくところは」「などです。」だけを
個別に抽出する可能性はまずないだろ?
こういう場合なら別に匿名ブロックができても良いと思う。
(しつこいけど、「div じゃなく p だろ」とか言うことではなくね)
ただ、初心者の頃は「どこまで OK?」みたいな判断が難しいと思うし、
始めからそういう書き方をしてると、変な癖が付きそうな気もするから、
最初は余りそういう書き方はしない方が良い気もする、と。そういう感じ。
<div>
今日の出来事
<p>色んなことがありました。</p>
</div>
例えばこういうのは余り好ましくない。
dl や h1 でマークしろって言うのではなく、データとして扱いにくいから。
要するに、上のような状態では「今日の出来事」という部分だけを
要素として抽出することができないんだよね
(こういうのを匿名ブロックと言う)。
↓ちょっと違うけどこれが似ている感じ。
http://pc.2ch.net/test/read.cgi/hp/984950028/438-439n
ただし、
<div>
よくいくところは
<ul>
<li>2ch</li>
<li>W3C</li>
</ul>
などです。
</div>
みたいなケースでは、「よくいくところは」「などです。」だけを
個別に抽出する可能性はまずないだろ?
こういう場合なら別に匿名ブロックができても良いと思う。
(しつこいけど、「div じゃなく p だろ」とか言うことではなくね)
ただ、初心者の頃は「どこまで OK?」みたいな判断が難しいと思うし、
始めからそういう書き方をしてると、変な癖が付きそうな気もするから、
最初は余りそういう書き方はしない方が良い気もする、と。そういう感じ。
249 ：Name_Not_Found：02/04/20 23:50 ID:CY4lq/4F
>>247
l 要素 は、多分 br の代替扱いだから、それはちょっと違うと思う。
<p>古池や<br/>
かはづとびこむ<br/>
みづのおと</p>
改め
<p>
<l>古池や</l>
<l>かはづとびこむ</l>
<l>みづのおと</l>
</p>
という感じに「行(Line)」を表す…のではないかと。
<p>HTML 4.01 には <ul>…</ul> の三種類があります。</p>
というのは、上記 >>248 の通り、データの性質上問題のない記述だと思う。
(DTD がこの記述を許していれば、ね)
l 要素 は、多分 br の代替扱いだから、それはちょっと違うと思う。
<p>古池や<br/>
かはづとびこむ<br/>
みづのおと</p>
改め
<p>
<l>古池や</l>
<l>かはづとびこむ</l>
<l>みづのおと</l>
</p>
という感じに「行(Line)」を表す…のではないかと。
<p>HTML 4.01 には <ul>…</ul> の三種類があります。</p>
というのは、上記 >>248 の通り、データの性質上問題のない記述だと思う。
(DTD がこの記述を許していれば、ね)
250 ：Name_Not_Found：02/04/21 00:16 ID:NZneqrgD
http://pc.2ch.net/test/read.cgi/hp/1002798055/
なんか変な人が出てるんですが・・・
なんか変な人が出てるんですが・・・
251 ：1：02/04/21 01:41 ID:Xgl/qCAC
>>248
だとすると、目次などでよく使われている下記のようなマークアップも
好ましくないということですか？
<ul>
<li>第一章</li>
<li>第二章
<ul>
<li>第二章 第一節</li>
<li>第二章 第二節</li>
</ul>
</li>
<li>第三章</li>
</ul>
この場合、「第二章」の部分が匿名ブロックになってる訳だけど、
こういうのをマークアップする適切な要素って何なんだろう。
だとすると、目次などでよく使われている下記のようなマークアップも
好ましくないということですか？
<ul>
<li>第一章</li>
<li>第二章
<ul>
<li>第二章 第一節</li>
<li>第二章 第二節</li>
</ul>
</li>
<li>第三章</li>
</ul>
この場合、「第二章」の部分が匿名ブロックになってる訳だけど、
こういうのをマークアップする適切な要素って何なんだろう。
>>251
現状では、以下の様にするのがベターかと。
飽くまで、ベターであって、ベストとか正解ではないのだが。
<dl>
<dt>第一章</dt>
<dt>第二章</dt>
<dd>
<ul>
<li>第二章 第一節</li>
<li>第二章 第二節</li>
</ul>
</dd>
<dt>第三章</dt>
</dl>
現状では、以下の様にするのがベターかと。
飽くまで、ベターであって、ベストとか正解ではないのだが。
<dl>
<dt>第一章</dt>
<dt>第二章</dt>
<dd>
<ul>
<li>第二章 第一節</li>
<li>第二章 第二節</li>
</ul>
</dd>
<dt>第三章</dt>
</dl>
253 ：Name_Not_Found：02/04/21 09:01 ID:GSavLmlN
>>183
>それは痛いほどわかっているんですけど、XHTML1.1以降はTranstionalが完全に消えましたからね。将来性も考えると…
データはXHTML1.1で管理し、UAがNN4.xならばサーバ側XSLTでXHTML1.0Transitionalに変換する、という処理でいけるはず。
互換性を確保するためには少々の苦労は仕方ないかと。
>それは痛いほどわかっているんですけど、XHTML1.1以降はTranstionalが完全に消えましたからね。将来性も考えると…
データはXHTML1.1で管理し、UAがNN4.xならばサーバ側XSLTでXHTML1.0Transitionalに変換する、という処理でいけるはず。
互換性を確保するためには少々の苦労は仕方ないかと。
254 ：Name_Not_Found：02/04/21 10:43 ID:xjaDdIjB
>>253
うちの鯖さくらなんですよ。鯖で変換するにはソフトウェアをさくらの鯖に入れなければいけないので難しいかも。
うちの鯖さくらなんですよ。鯖で変換するにはソフトウェアをさくらの鯖に入れなければいけないので難しいかも。
255 ：Name_Not_Found：02/04/21 10:59 ID:xjaDdIjB
256 ：Name_Not_Found：02/04/21 11:10 ID:xjaDdIjB
よく見ると
「段落等の中での各行 (line) を表す; br要素の置き換え(?)」
となってるので、段落等の中で使うのが適切なようです。
「段落等の中での各行 (line) を表す; br要素の置き換え(?)」
となってるので、段落等の中で使うのが適切なようです。
257 ：Name_Not_Found：02/04/21 14:23 ID:GSavLmlN
>>254
じゃあ、作成するときに変換してもいいでしょ?
>>255
おいおい、現行のブラウザが対応しているわけないだろ
>247のでは改行されていました。
l要素のために改行されたのではありません。ul要素のためです。
じゃあ、作成するときに変換してもいいでしょ?
>>255
おいおい、現行のブラウザが対応しているわけないだろ
>247のでは改行されていました。
l要素のために改行されたのではありません。ul要素のためです。
258 ：Name_Not_Found：02/04/21 15:31 ID:smgBuYhd
>>257
ってことは、l要素はCSS未対応な古いUAはさっぱり無視する仕様なわけね？
ってことは、l要素はCSS未対応な古いUAはさっぱり無視する仕様なわけね？
259 ：Name_Not_Found：02/04/21 15:33 ID:smgBuYhd
260 ：Name_Not_Found：02/04/21 16:13 ID:7J9YpGhT
>>255
ユーザスタイルシートで l {display:block;}
もしくは l:after {content:"\A";} を指定すれば解決。
>>258
つーか、本当の意味での「スタイルシート未対応のブラウザ」ってのは、
table や font についても一切の整形を行わないブラウザを
指すんだと思うが。(煽りｽﾏｿ)
HTML 3.2 に対する HTML 4.0 だって、当然新しい要素を追加するために
制定されたんだし。CSS のなかった当時に比べれて、
見栄えに関しては完全な後方互換となっているとも言える。
ユーザスタイルシートで l {display:block;}
もしくは l:after {content:"\A";} を指定すれば解決。
>>258
つーか、本当の意味での「スタイルシート未対応のブラウザ」ってのは、
table や font についても一切の整形を行わないブラウザを
指すんだと思うが。(煽りｽﾏｿ)
HTML 3.2 に対する HTML 4.0 だって、当然新しい要素を追加するために
制定されたんだし。CSS のなかった当時に比べれて、
見栄えに関しては完全な後方互換となっているとも言える。
261 ：Name_Not_Found：02/04/21 16:45 ID:juYJcEo4
>>258
データが整形表示されないことを無視というならそのとおり。
XML データを処理できないブラウザは、たとえ CSS に対応してても整形できないだろう。
それでも MIME を text/xml とか application/xhtml+xml とかにしとけば
まともな未対応 UA なら処理方法を問い合わせたり外部アプリに渡したりするはず。
何も全てのデータを UA の中で処理しなければならないわけではないから。
それさえできるなら、 UA は UA としての仕事を果たしている。
XML(含XHTML) は別に HTML ブラウザで表示できなきゃいけないものではないよ。
そもそも表示すること自体、最終目的じゃない。
「無視」って言い方になっちゃう気持ちは解らなくないけどね。
データが整形表示されないことを無視というならそのとおり。
XML データを処理できないブラウザは、たとえ CSS に対応してても整形できないだろう。
それでも MIME を text/xml とか application/xhtml+xml とかにしとけば
まともな未対応 UA なら処理方法を問い合わせたり外部アプリに渡したりするはず。
何も全てのデータを UA の中で処理しなければならないわけではないから。
それさえできるなら、 UA は UA としての仕事を果たしている。
XML(含XHTML) は別に HTML ブラウザで表示できなきゃいけないものではないよ。
そもそも表示すること自体、最終目的じゃない。
「無視」って言い方になっちゃう気持ちは解らなくないけどね。
> そもそも表示すること自体、最終目的じゃない。
語弊のある表現だったかもしれない。
表示することは目的の全てではない、くらいが適当か。
語弊のある表現だったかもしれない。
表示することは目的の全てではない、くらいが適当か。
263 ：Name_Not_Found：02/04/21 17:45 ID:7J9YpGhT
要するに、XHTML 2.0 は旧来の意味での HTML じゃないんだから、
旧来の HTML ブラウザで閲覧ができないのは当然というか。
>>261 が(暗に)言っているように、XHTML 2.0 は XML として扱うべきもの。
旧来の UA のために XML の機能を不使用にした XHTML 1.x ファミリは、
その意味では全て Transitional な XHTML だと思う。
旧来の HTML ブラウザで閲覧ができないのは当然というか。
>>261 が(暗に)言っているように、XHTML 2.0 は XML として扱うべきもの。
旧来の UA のために XML の機能を不使用にした XHTML 1.x ファミリは、
その意味では全て Transitional な XHTML だと思う。
headのprofile属性を使用したいけど書式はないっすよね？
んじゃ自由ですか？
h1の次にh3を書くのは自由だけど、あんまよろしくないというように
自由のなかにもこれはダメ？ってのあります？
基本的にlink要素とmeta要素の補足説明を書いていく予定。
んじゃ自由ですか？
h1の次にh3を書くのは自由だけど、あんまよろしくないというように
自由のなかにもこれはダメ？ってのあります？
基本的にlink要素とmeta要素の補足説明を書いていく予定。
265 ：Name_Not_Found：02/04/21 19:51 ID:GSavLmlN
266 ：Name_Not_Found：02/04/21 20:18 ID:0p4LwMyD
267 ：Name_Not_Found：02/04/21 21:31 ID:juYJcEo4
268 ：Name_Not_Found：02/04/21 22:51 ID:/+xhKk/x
>>264
漏れも気になっていたんだが…多分いいんだと思う…多分。
参考↓リンクタイプに 'meta' を追加する実例(Dublin Core 用)
ttp://infomesh.net/2001/uriprofile/
Dublin Core については↓
ttp://www.kanzaki.com/docs/sw/dublin-core.html
漏れも気になっていたんだが…多分いいんだと思う…多分。
参考↓リンクタイプに 'meta' を追加する実例(Dublin Core 用)
ttp://infomesh.net/2001/uriprofile/
Dublin Core については↓
ttp://www.kanzaki.com/docs/sw/dublin-core.html
269 ：Name_Not_Found：02/04/21 23:09 ID:0p4LwMyD
>>267
＞「Strict的にも辛く」とはどういう観点？
同じ内容のドキュメントを複数持つのはどうかと言う話。
ポイントを指す時にも困る。
Content Negotiation が行える鯖なら困らないけど。
＞「Strict的にも辛く」とはどういう観点？
同じ内容のドキュメントを複数持つのはどうかと言う話。
ポイントを指す時にも困る。
Content Negotiation が行える鯖なら困らないけど。
270 ：Name_Not_Found：02/04/22 09:34 ID:VuKi5ptX
>>269
> 同じ内容のドキュメントを複数持つのはどうかと言う話。
そのための link rel="alternate" です、と言ってみるテスト。
例えば HTML4.01 仕様書は HTML 版, PDF 版, PostScript 版, Plain Text 版と 4 種類存在して
HTML 版のアーカイブは tar.gz 版と zip 版の 2 種類がある。
利用者は環境や目的に合わせて、最適な形式を自分で選択できる。
同じ内容であるならば、ここに XML 版や HTML3.2 版が加わったからといって何も問題はない。
問題が出るのは、各版で内容が異なる場合だ。
でもそれは鯖側で変換や Content Negotiation をする場合でも
同じように考慮しなければならないことじゃない？
# 同じURLでUAによって文面が違ってたりしたら、むしろそっちの方が問題。
> 同じ内容のドキュメントを複数持つのはどうかと言う話。
そのための link rel="alternate" です、と言ってみるテスト。
例えば HTML4.01 仕様書は HTML 版, PDF 版, PostScript 版, Plain Text 版と 4 種類存在して
HTML 版のアーカイブは tar.gz 版と zip 版の 2 種類がある。
利用者は環境や目的に合わせて、最適な形式を自分で選択できる。
同じ内容であるならば、ここに XML 版や HTML3.2 版が加わったからといって何も問題はない。
問題が出るのは、各版で内容が異なる場合だ。
でもそれは鯖側で変換や Content Negotiation をする場合でも
同じように考慮しなければならないことじゃない？
# 同じURLでUAによって文面が違ってたりしたら、むしろそっちの方が問題。
271 ：Name_Not_Found：02/04/22 12:49 ID:KPhbT6yF
サーバサイドでは基本のXMLをひとつ用意して、
XSLT で XHTML 1.1 / XHTML 2.0 / その他のXML に変換する、
という方法もある。
XSLT で XHTML 1.1 / XHTML 2.0 / その他のXML に変換する、
という方法もある。
272 ：Name_Not_Found：02/04/22 16:25 ID:0tGkRcYn
>>271
XHTML2.0はワーキングドラフトすら出てないんじゃない？
XHTML2.0はワーキングドラフトすら出てないんじゃない？
273 ：Name_Not_Found：02/04/22 16:47 ID:ZIuwPNJ3
早くでないかなあ。>XHTML 2.0 WD
274 ：Name_Not_Found：02/04/22 18:49 ID:do6Ip3rA
企画も大切だとは思うが、実装も追いついてﾎｼｨ
275 ：Name_Not_Found：02/04/22 18:54 ID:mlVJB009
ほんまにほんまに。
276 ：Name_Not_Found：02/04/22 20:49 ID:Yf2tCvqU
s/企画/規格/g
277 ：Name_Not_Found：02/04/24 13:45 ID:/6Syqg5g
278 ：公正：02/04/24 14:00 ID:UTxuqQMn
フォントサイズの指定の仕方には、
SI単位(国際単位系)を使うのが世界標準です。
「pt」,「px」,「em」などの単位は認められておらず、
「cm」を使わなければなりません。
SI単位(国際単位系)を使うのが世界標準です。
「pt」,「px」,「em」などの単位は認められておらず、
「cm」を使わなければなりません。
279 ：Name_Not_Found：02/04/24 14:21 ID:kEKWawLY
>>277
そのまま引用でいいんじゃネーノ？
そのまま引用でいいんじゃネーノ？
280 ：Name_Not_Found：02/04/24 14:27 ID:lR7bsFdx
>>277
classで「引用の見出し」とマークアップするのが一番良かったりして。
classで「引用の見出し」とマークアップするのが一番良かったりして。
281 ：Name_Not_Found：02/04/24 14:31 ID:wxxbdI5V
282 ：Name_Not_Found：02/04/24 14:40 ID:lR7bsFdx
引用するのは内容なんだから
基本的な構造さえ維持してればマークアップに気を遣うことないんじゃ。
fontが明らかに強調目的ならemにしてもいいと思う。
というかせざるを得ない。
＞blockquote の中は別世界
それ考えたけど、自分の場合は(2)になる。
基本的な構造さえ維持してればマークアップに気を遣うことないんじゃ。
fontが明らかに強調目的ならemにしてもいいと思う。
というかせざるを得ない。
＞blockquote の中は別世界
それ考えたけど、自分の場合は(2)になる。
283 ：Name_Not_Found：02/04/24 14:44 ID:pMshZBXx
>>277
俺も(1)だな。
引用部分内は他人の文章じゃん。
自分の文章の見出しと他人の文章の見出しが
見出しのレベルの整合性を持っている必要はないと思う。
>>282
引用って「部分」だと思うんだけど、「一つの文書」になっちゃうの？
俺も(1)だな。
引用部分内は他人の文章じゃん。
自分の文章の見出しと他人の文章の見出しが
見出しのレベルの整合性を持っている必要はないと思う。
>>282
引用って「部分」だと思うんだけど、「一つの文書」になっちゃうの？
284 ：Name_Not_Found：02/04/24 14:50 ID:lR7bsFdx
>>282
強調なのか弱調(?)なのか定義語なのか単に色を変えたいだけなのか
はっきりわからない時があるんだよね。
そーゆーのも全部まとめて em にしちゃっていいのかなーと。
# まあ、font 要素を無視するのも手なんだけど。
強調なのか弱調(?)なのか定義語なのか単に色を変えたいだけなのか
はっきりわからない時があるんだよね。
そーゆーのも全部まとめて em にしちゃっていいのかなーと。
# まあ、font 要素を無視するのも手なんだけど。
287 ：Name_Not_Found：02/04/24 16:03 ID:pMshZBXx
>>286
「マークアップは筆者による」ってのはどうかな。
よくあるじゃん、「傍点は～」っての。
断り書き入れて、原文の URL とか入れて
読者が原文を参照できるようにしてけば、大きな問題はないんじゃない？
元々マークアップされていない一般書籍や PDF 文書から引用する場合は
それこそ著者が勝手にマークアップするしかないわけだし。
「マークアップは筆者による」ってのはどうかな。
よくあるじゃん、「傍点は～」っての。
断り書き入れて、原文の URL とか入れて
読者が原文を参照できるようにしてけば、大きな問題はないんじゃない？
元々マークアップされていない一般書籍や PDF 文書から引用する場合は
それこそ著者が勝手にマークアップするしかないわけだし。
288 ：Name_Not_Found：02/04/24 16:15 ID:kEKWawLY
289 ：Name_Not_Found：02/04/24 18:35 ID:dwYFHaef
(3)だと思います。blockquoteはテキストを引用するもの(仕様書参照)でタグを引用するものではない。テキストは原文のままであることが求められるが、タグは柔軟性が許容される。
290 ：茶文字 ◆xELvisFU ：02/04/24 19:01 ID:Na+aFH85
引用する際の文脈も無視できないとﾁｮﾄ思った。
たとえば以下のような日記の構造だとする。
<h1>バイク便日記</h1>
<h2>4/24 (水)</h2>
<h3>はれ</h>
<p>総走行距離245km、燃費22km/l。思ったより市街地の渋滞がひどかった。</p>
これを他の人が参考にして、表を作ると考えたらどうだろう。
<blockquote>
<table>
<caption>○○市のバイク便の燃費</caption>
<thead>
<tr><th>日付(曜日)</th><th>走行距離</th><th>燃費</th><th>メモ</th></tr>
<tbody>
<tr>
<td>4/24(水)</td><td>245</td><td>22</td><td>思ったより市街地の渋滞がひどかった</td>
</tr>
</tbody>
</table>
</blockquote>
こういう形を引用と呼ぶべきではないかも知れないけど、
必要な部分だけを抜き出して比較したいときなどは
元の文書のマークアップを踏襲しない方がよいな、と思った。
たとえば以下のような日記の構造だとする。
<h1>バイク便日記</h1>
<h2>4/24 (水)</h2>
<h3>はれ</h>
<p>総走行距離245km、燃費22km/l。思ったより市街地の渋滞がひどかった。</p>
これを他の人が参考にして、表を作ると考えたらどうだろう。
<blockquote>
<table>
<caption>○○市のバイク便の燃費</caption>
<thead>
<tr><th>日付(曜日)</th><th>走行距離</th><th>燃費</th><th>メモ</th></tr>
<tbody>
<tr>
<td>4/24(水)</td><td>245</td><td>22</td><td>思ったより市街地の渋滞がひどかった</td>
</tr>
</tbody>
</table>
</blockquote>
こういう形を引用と呼ぶべきではないかも知れないけど、
必要な部分だけを抜き出して比較したいときなどは
元の文書のマークアップを踏襲しない方がよいな、と思った。
291 ：Name_Not_Found：02/04/24 19:10 ID:Dlho/a2i
>>290
その場合はq要素の方が適切では。
その場合はq要素の方が適切では。
292 ：茶文字 ◆xELvisFU ：02/04/24 19:21 ID:Na+aFH85
>>291
うむむ。
やはりそれぞれのtd要素に対してqでマークアップするべき？
なるべく高次の親要素に引用であることを示すマークアップを入れた方が
スマートだと思ったんだけど。
trやtbodyにcite属性が使えないからなぁ。
話それちゃってｺﾞﾒｿ。
うむむ。
やはりそれぞれのtd要素に対してqでマークアップするべき？
なるべく高次の親要素に引用であることを示すマークアップを入れた方が
スマートだと思ったんだけど。
trやtbodyにcite属性が使えないからなぁ。
話それちゃってｺﾞﾒｿ。
>>290
マークアップそのものは、新しい文書や文書の HTML / XHTML の仕様に基づいて
引用者が書き直すべきだが、元々「表」ではないデータを「表」にするのは
マークアップ上の問題ではなく、引用の仕方として問題がある。
どうしても（自分で表形式に書き換えた）表のデータの出所を明らかに
したければ、データにリンクでも付け、「<cite>ドコソコ</cite>の
<q>○○</q> との記述に基づく」と解説を書くべき。
マークアップそのものは、新しい文書や文書の HTML / XHTML の仕様に基づいて
引用者が書き直すべきだが、元々「表」ではないデータを「表」にするのは
マークアップ上の問題ではなく、引用の仕方として問題がある。
どうしても（自分で表形式に書き換えた）表のデータの出所を明らかに
したければ、データにリンクでも付け、「<cite>ドコソコ</cite>の
<q>○○</q> との記述に基づく」と解説を書くべき。
>>277
リンクできる WWW 上の HTML の場合、俺は可能な限りリンクを張って
ごまかし、4 になるようにしている。どうしても見出しを引用せねばならない時は、
3 にしている。
＃引用は、引用先の文書が主、引用が従となるように書かかねばならない、という
引用の原則から、引用文は (他者の著作物であるが) 引用先の文書の一部、
という解釈
…早く XHTML 2.0 が勧告されてレベルを気にしない見出しが使えるようにならないかなぁ…
リンクできる WWW 上の HTML の場合、俺は可能な限りリンクを張って
ごまかし、4 になるようにしている。どうしても見出しを引用せねばならない時は、
3 にしている。
＃引用は、引用先の文書が主、引用が従となるように書かかねばならない、という
引用の原則から、引用文は (他者の著作物であるが) 引用先の文書の一部、
という解釈
…早く XHTML 2.0 が勧告されてレベルを気にしない見出しが使えるようにならないかなぁ…
295 ：277：02/04/24 20:14 ID:OGlCK3HC
296 ：Name_Not_Found：02/04/24 20:28 ID:/GDubzG3
>>277-294
blockquote の中の見出しを h1 などでマークするのは宜しくないと思います。
CSS の counter で見出しに番号を振るような場合や、
ブラウザの見出しジャンプとかの機能なんかを想定すれば
解ると思うんですが。(まぁ、blockquote h1 を特別扱いする手はあるけど)
つーことで、h1-h6 は「本文の構造を作る」見出しのマークに対してのみ
用いるべきだと漏れは思います。
<h4>4月1日</h4>
<p>晴れ。</p>
<h4>4月2日</h4>
<p>曇り。</p>
を引用するなら、
<dl>
<dt>4月1日</dt>
<dd>
<p>晴れ。</p>
</dd>
<dt>4月2日</dt>
<dd>
<p>曇り。</p>
</dd>
</dl>
辺りが適切ではないかと。
blockquote の中の見出しを h1 などでマークするのは宜しくないと思います。
CSS の counter で見出しに番号を振るような場合や、
ブラウザの見出しジャンプとかの機能なんかを想定すれば
解ると思うんですが。(まぁ、blockquote h1 を特別扱いする手はあるけど)
つーことで、h1-h6 は「本文の構造を作る」見出しのマークに対してのみ
用いるべきだと漏れは思います。
<h4>4月1日</h4>
<p>晴れ。</p>
<h4>4月2日</h4>
<p>曇り。</p>
を引用するなら、
<dl>
<dt>4月1日</dt>
<dd>
<p>晴れ。</p>
</dd>
<dt>4月2日</dt>
<dd>
<p>曇り。</p>
</dd>
</dl>
辺りが適切ではないかと。
297 ：Name_Not_Found：02/04/24 20:38 ID:56S9eCbt
いっそ別ファイルにしてobjectで挿入(w
298 ：Name_Not_Found：02/04/24 20:47 ID:28LewhIg
>>297
(・∀・)ｿﾚﾀﾞ!
(・∀・)ｿﾚﾀﾞ!
299 ：Name_Not_Found：02/04/24 21:18 ID:4VTKQhJt
300 ：Name_Not_Found：02/04/24 21:26 ID:dqg9m2nM
引用元に直リン張って「ココを先に読め！」じゃ駄目なの?
引用元がデットリンクになったら素直に諦めるって方向で。
…やっぱりスレ違いだ…。
引用元がデットリンクになったら素直に諦めるって方向で。
…やっぱりスレ違いだ…。
301 ：Name_Not_Found：02/04/24 22:49 ID:dwYFHaef
>>295
引用部がはっきりしないのでよろしくない。
> <p>以下は、××さんの日記の引用です。</p>
という説明がある限り、以下の文は"××さんの日記"という引用のひとまとまりであるはずである。>>289で解決してしまっていいと思う。
>>290
これは、引用ではない。まとめである。よってblockquoteもqも不適切。
引用部がはっきりしないのでよろしくない。
> <p>以下は、××さんの日記の引用です。</p>
という説明がある限り、以下の文は"××さんの日記"という引用のひとまとまりであるはずである。>>289で解決してしまっていいと思う。
>>290
これは、引用ではない。まとめである。よってblockquoteもqも不適切。
302 ：Name_Not_Found：02/04/24 22:58 ID:dwYFHaef
>>296
"見出し"構造と"リスト"構造の用法は必ずしも一致しない。
<h1>見出し</h1><p>内容</p>
この場合見出しは内容の要約や地位を表す。
<dt>A</dt><dd>B</dd>
この場合A=Bであることを表す。
blockquote内のheading要素を特別扱いするほうがより汎用的に対処できるかと。
"見出し"構造と"リスト"構造の用法は必ずしも一致しない。
<h1>見出し</h1><p>内容</p>
この場合見出しは内容の要約や地位を表す。
<dt>A</dt><dd>B</dd>
この場合A=Bであることを表す。
blockquote内のheading要素を特別扱いするほうがより汎用的に対処できるかと。
303 ：Name_Not_Found：02/04/24 23:21 ID:/GDubzG3
>>302
> <dt>A</dt><dd>B</dd>
> この場合A=Bであることを表す。
そんなことはないよ。定義リストはもっと柔軟に使ってよいもの。
> blockquote 内の heading 要素を特別扱いするほうがより汎用的に対処できるかと。
もしこれを認めてしまうと、例えば「メニュー表示用に見出しを抽出したリスト」
なんてのも h1-h6 でマークしてよいことになるだろうし、
同じ論法で「文書本体の構造を示す h1-h6」以外の h1-h6 を
(blockquote 内のみならず、他の要素内でも)
勝手に使って良いことになってしまうでしょう。
そうすると、見出しジャンプや見出しを用いた本文の折り畳み、
見出しを抜き出した目次の作成なんてのは一切不可能になってしまいます。
これでは h1-h6 を定義した意味がありません。
> <dt>A</dt><dd>B</dd>
> この場合A=Bであることを表す。
そんなことはないよ。定義リストはもっと柔軟に使ってよいもの。
> blockquote 内の heading 要素を特別扱いするほうがより汎用的に対処できるかと。
もしこれを認めてしまうと、例えば「メニュー表示用に見出しを抽出したリスト」
なんてのも h1-h6 でマークしてよいことになるだろうし、
同じ論法で「文書本体の構造を示す h1-h6」以外の h1-h6 を
(blockquote 内のみならず、他の要素内でも)
勝手に使って良いことになってしまうでしょう。
そうすると、見出しジャンプや見出しを用いた本文の折り畳み、
見出しを抜き出した目次の作成なんてのは一切不可能になってしまいます。
これでは h1-h6 を定義した意味がありません。
304 ：Name_Not_Found：02/04/24 23:25 ID:dwYFHaef
>>303
>「メニュー表示用に見出しを抽出したリスト」
リストを見出しとしてマークアップすることは不適切。"'見出し'構造と'リスト'構造の用法は必ずしも一致しない。"というのはそういうことです。
> そうすると、見出しジャンプや見出しを用いた本文の折り畳み、
引用の文章であっても程度の長さがあれば、折りたためたほうが便利ですよね？
>「メニュー表示用に見出しを抽出したリスト」
リストを見出しとしてマークアップすることは不適切。"'見出し'構造と'リスト'構造の用法は必ずしも一致しない。"というのはそういうことです。
> そうすると、見出しジャンプや見出しを用いた本文の折り畳み、
引用の文章であっても程度の長さがあれば、折りたためたほうが便利ですよね？
305 ：Name_Not_Found：02/04/24 23:46 ID:/04bATSO
>>303
結局の所、引用先の文章にとって、h1～h6 でマークアップするに
相応しいかどうか、と言う事になるんでしょうか。
>>277
引用文の見出しは blockquote の title 属性に書く、という方法を提案。
結局の所、引用先の文章にとって、h1～h6 でマークアップするに
相応しいかどうか、と言う事になるんでしょうか。
>>277
引用文の見出しは blockquote の title 属性に書く、という方法を提案。
306 ：Name_Not_Found：02/04/24 23:47 ID:pMshZBXx
>>303
> そうすると、見出しジャンプや見出しを用いた本文の折り畳み、
> 見出しを抜き出した目次の作成なんてのは一切不可能になってしまいます。
自分でそういうスクリプトを書いていて
これを行う際に blockquote 内の見出しは必要ないと思った。
たとえ見出しレベルの矛盾を解決しても、
やはり著者による本文の見出し構造とは直接関係ないものだ。
俺は最終的に blockquote 内の見出しは見出しリストから外すことにした。
特別扱いってより、無視って感じ。
どうやったってなんかしらの矛盾を抱えるものだと思う。
> そうすると、見出しジャンプや見出しを用いた本文の折り畳み、
> 見出しを抜き出した目次の作成なんてのは一切不可能になってしまいます。
自分でそういうスクリプトを書いていて
これを行う際に blockquote 内の見出しは必要ないと思った。
たとえ見出しレベルの矛盾を解決しても、
やはり著者による本文の見出し構造とは直接関係ないものだ。
俺は最終的に blockquote 内の見出しは見出しリストから外すことにした。
特別扱いってより、無視って感じ。
どうやったってなんかしらの矛盾を抱えるものだと思う。
307 ：Name_Not_Found：02/04/25 06:57 ID:GJGL5DdZ
世界の視線はホームページ制作王に集約されている。
21世紀のWEBは制作王が統治するのだ。
君達も先見性に目覚めるべきだ。
21世紀のWEBは制作王が統治するのだ。
君達も先見性に目覚めるべきだ。
308 ：277：02/04/25 12:55 ID:qynUVKCc
>>301
「以下は～引用です」という文章をとっぱらえば問題ないと思いますが。
それから、引用文の見出し（h1～6）と本文（blockquote）に、
title="××さんの日記より"という属性をつけてやれば、より明確になるし。
あとは、全体を<div class="quote" title="××さんの日記より">で囲ってやる
という手もあるけど、Strict的には邪道かな。
>>302
> blockquote内のheading要素を特別扱いするほうがより汎用的に対処できるかと。
文書を利用するのは著者自身だけではないので、そういうコンセンサスが得られて
いない以上、避けた方がいいと思います。
（たとえば他人の書いた文書の見出しを自動抽出して目次を作ったりすることも
ありえるので）
「以下は～引用です」という文章をとっぱらえば問題ないと思いますが。
それから、引用文の見出し（h1～6）と本文（blockquote）に、
title="××さんの日記より"という属性をつけてやれば、より明確になるし。
あとは、全体を<div class="quote" title="××さんの日記より">で囲ってやる
という手もあるけど、Strict的には邪道かな。
>>302
> blockquote内のheading要素を特別扱いするほうがより汎用的に対処できるかと。
文書を利用するのは著者自身だけではないので、そういうコンセンサスが得られて
いない以上、避けた方がいいと思います。
（たとえば他人の書いた文書の見出しを自動抽出して目次を作ったりすることも
ありえるので）
309 ：沢渡 ◆xkv/kqy2 ：02/04/25 13:18 ID:fIayCELc
あのさ、これを読んでて気がついたんだけど、英単語の前後に半角スペース入れてる人いるよね。
>>306さんとか。
これ凄く読みやすくて自分も今度からそうしようと思ったんだけど。
Strict 的には半角スペースを入れるのはNGっすかね？（意味の無い半角スペース）
だからといって、 CSS で letter-spacing すると一文字一文字離れちゃうし…。
>>306さんとか。
これ凄く読みやすくて自分も今度からそうしようと思ったんだけど。
Strict 的には半角スペースを入れるのはNGっすかね？（意味の無い半角スペース）
だからといって、 CSS で letter-spacing すると一文字一文字離れちゃうし…。
310 ：Name_Not_Found：02/04/25 13:23 ID:bJ1e67nw
>>309
前後の半角スペースまで英語の規則と考えればアリか？
前後の半角スペースまで英語の規則と考えればアリか？
311 ：Name_Not_Found：02/04/25 13:26 ID:pyymqWJP
312 ：Name_Not_Found：02/04/25 13:45 ID:hOyXZnCM
>>309
CSS3 text で検討されてはいる。
http://www.w3.org/TR/2001/WD-css3-text-20010517/#text-autospace-prop
スペース入れるのが Strict 的にどうなのかは俺にはなんとも判断できないけど。
CSS3 text で検討されてはいる。
http://www.w3.org/TR/2001/WD-css3-text-20010517/#text-autospace-prop
スペース入れるのが Strict 的にどうなのかは俺にはなんとも判断できないけど。
313 ：Name_Not_Found：02/04/25 13:48 ID:CKMGHa2C
314 ： ：02/04/25 13:58 ID:AyILwMbE
>309
以前は僕も半角スペース入れてたんだが，読み上げブラウザで
「2 月」が「に つき」と読まれたり，「A 君」が「えー きみ」とか読まれるので今は全部詰めるようにした．
以前は僕も半角スペース入れてたんだが，読み上げブラウザで
「2 月」が「に つき」と読まれたり，「A 君」が「えー きみ」とか読まれるので今は全部詰めるようにした．
315 ：Name_Not_Found：02/04/25 14:46 ID:OmE2lATP
>>314
どっちにしろそれはスペース空けるべきところじゃないと思う。
2月もA君もひとつの単語でしょ。
要素や属性名を書く時なら自分はcodeでマークして
padding 取ったりフォント変えたりしてたけど、
それ以外となるとやっぱりスペース入れるかな。
どっちにしろそれはスペース空けるべきところじゃないと思う。
2月もA君もひとつの単語でしょ。
要素や属性名を書く時なら自分はcodeでマークして
padding 取ったりフォント変えたりしてたけど、
それ以外となるとやっぱりスペース入れるかな。
316 ： ：02/04/25 15:02 ID:AyILwMbE
>315
それはまあそのとおりで，以前は空けるべきじゃなかったところも空けてたのはまずかった．
で，今は，ものによって単語と見なせるかどうかを考えるのが面倒
（というか，自分の中で基準を完全に統一するのが難しい）ので，とりあえず全部詰めるように．
それはまあそのとおりで，以前は空けるべきじゃなかったところも空けてたのはまずかった．
で，今は，ものによって単語と見なせるかどうかを考えるのが面倒
（というか，自分の中で基準を完全に統一するのが難しい）ので，とりあえず全部詰めるように．
318 ：Name_Not_Found：02/04/25 17:35 ID:z1ZCz0KB
>>308
>「以下は～引用です」という文章をとっぱらえば問題ないと思いますが。
>それから、引用文の見出し（h1～6）と本文（blockquote）に、
>title="××さんの日記より"という属性をつけてやれば、より明確になるし。
>あとは、全体を<div class="quote" title="××さんの日記より">で囲ってやる
>という手もあるけど、Strict的には邪道かな。
なぜあえて邪道な道に進もうとするのか。短い引用ならblockquote+title属性、長い引用ならblockquote+見出し要素でまったく問題ない。
>>302
> blockquote内のheading要素を特別扱いするほうがより汎用的に対処できるかと。
>文書を利用するのは著者自身だけではないので、そういうコンセンサスが得られて
>いない以上、避けた方がいいと思います。
>（たとえば他人の書いた文書の見出しを自動抽出して目次を作ったりすることも
ありえるので）
しかしblockquoteの中に見出し要素が許容される以上、抽出する人はそのことを考えて目次を作らなければならないのではないでしょうか?
>「以下は～引用です」という文章をとっぱらえば問題ないと思いますが。
>それから、引用文の見出し（h1～6）と本文（blockquote）に、
>title="××さんの日記より"という属性をつけてやれば、より明確になるし。
>あとは、全体を<div class="quote" title="××さんの日記より">で囲ってやる
>という手もあるけど、Strict的には邪道かな。
なぜあえて邪道な道に進もうとするのか。短い引用ならblockquote+title属性、長い引用ならblockquote+見出し要素でまったく問題ない。
>>302
> blockquote内のheading要素を特別扱いするほうがより汎用的に対処できるかと。
>文書を利用するのは著者自身だけではないので、そういうコンセンサスが得られて
>いない以上、避けた方がいいと思います。
>（たとえば他人の書いた文書の見出しを自動抽出して目次を作ったりすることも
ありえるので）
しかしblockquoteの中に見出し要素が許容される以上、抽出する人はそのことを考えて目次を作らなければならないのではないでしょうか?
319 ：Name_Not_Found：02/04/25 17:36 ID:z1ZCz0KB
320 ：277=295=308：02/04/25 21:59 ID:qynUVKCc
>>318
> なぜあえて邪道な道に進もうとするのか。
「全体を<div class="note"～で囲って」というのは、「引用部がはっきりしない
からよろしくない」というご意見に対して、そこに拘るなら（俺は拘らないけど）
そういう手もあるよ、と例示しただけで、俺自身はやりません。
> 短い引用ならblockquote+title属性
たしかに、295で俺が示した方法より、見出しで区切られた地の文ごとに区切って
引用し、title属性に引用元の見出しを書く、というやり方の方がいいかも。
各引用文の、原文における階層がわからなくなる、という欠点はありますが。
しかし、
> 長い引用ならblockquote+見出し要素でまったく問題ない。
これに関しては、すでに >>303 や >>308 で述べられている問題があるので、
「問題ない」と断言はできないと思うんですが。
> しかしblockquoteの中に見出し要素が許容される以上、抽出する人はそのことを
> 考えて目次を作らなければならないのではないでしょうか?
だから、「blockquoteの中の見出しをどう扱うべきか」という点について、
コンセンサスが得られていないのに、抽出する人に「blockquoteの中の
見出しは別扱い」というやり方を強要することはできないので、とりあえず
最初からそういうマークアップは避ける方が無難だと言ってるわけです。
それに、仕様やDTDの許容範囲ならどう書いてもいいというなら、そもそも
こういう議論自体が無意味では？
> なぜあえて邪道な道に進もうとするのか。
「全体を<div class="note"～で囲って」というのは、「引用部がはっきりしない
からよろしくない」というご意見に対して、そこに拘るなら（俺は拘らないけど）
そういう手もあるよ、と例示しただけで、俺自身はやりません。
> 短い引用ならblockquote+title属性
たしかに、295で俺が示した方法より、見出しで区切られた地の文ごとに区切って
引用し、title属性に引用元の見出しを書く、というやり方の方がいいかも。
各引用文の、原文における階層がわからなくなる、という欠点はありますが。
しかし、
> 長い引用ならblockquote+見出し要素でまったく問題ない。
これに関しては、すでに >>303 や >>308 で述べられている問題があるので、
「問題ない」と断言はできないと思うんですが。
> しかしblockquoteの中に見出し要素が許容される以上、抽出する人はそのことを
> 考えて目次を作らなければならないのではないでしょうか?
だから、「blockquoteの中の見出しをどう扱うべきか」という点について、
コンセンサスが得られていないのに、抽出する人に「blockquoteの中の
見出しは別扱い」というやり方を強要することはできないので、とりあえず
最初からそういうマークアップは避ける方が無難だと言ってるわけです。
それに、仕様やDTDの許容範囲ならどう書いてもいいというなら、そもそも
こういう議論自体が無意味では？
321 ：ロボ鉄 ◆MGTy6iYI ：02/04/25 22:44 ID:VSp8dYUu
あっ、バグってる
322 ：Name_Not_Found：02/04/25 23:40 ID:EBXFCGtn
不毛な論議は止めて、ホームページ制作王を使おう！
21世紀型webソリューションのスタンダードとして世界が認めた制作王。
もはや敵は存在しない。
21世紀型webソリューションのスタンダードとして世界が認めた制作王。
もはや敵は存在しない。
323 ：Name_Not_Found：02/04/25 23:42 ID:fhkCzi23
何処の世界ですか？
>「blockquoteの中の見出しをどう扱うべきか」という点について、
>コンセンサスが得られていないのに、抽出する人に「blockquoteの中の
>見出しは別扱い」というやり方を強要することはできない
引用文の中に出現する見出しが、通常の本文と異なり、例えば
見出しリストを作るときに抽出対象にすると不都合が起こる、という事は、
HTML とかマークアップ以前の「引用」という部分で自明のことと思われるが？
それに対し、H1-H6 は見出しをマークアップする、というコンセンサスが
取られており、例え引用文中であろうが、（その見出しレベルがそうなるかは
論議の余地は有るが）見出しである以上、h1-h6 でマークアップするのが
必然かと思われるが、どうだろうか。
>コンセンサスが得られていないのに、抽出する人に「blockquoteの中の
>見出しは別扱い」というやり方を強要することはできない
引用文の中に出現する見出しが、通常の本文と異なり、例えば
見出しリストを作るときに抽出対象にすると不都合が起こる、という事は、
HTML とかマークアップ以前の「引用」という部分で自明のことと思われるが？
それに対し、H1-H6 は見出しをマークアップする、というコンセンサスが
取られており、例え引用文中であろうが、（その見出しレベルがそうなるかは
論議の余地は有るが）見出しである以上、h1-h6 でマークアップするのが
必然かと思われるが、どうだろうか。
325 ：Name_Not_Found：02/04/25 23:46 ID:EBXFCGtn
326 ：Name_Not_Found：02/04/26 00:29 ID:xkMVo+ev
>>324
どこまで行っても見出しは見出しだから、という意味では
杓子定規にやればそうなると思う。
ただ、確実に不都合が存在していて、
それに対する解決策が見出せていない現状では、
>>320のいう「コンセンサスがない」というのも理解出来るから、
それを避ける（避け方は色々あるだろうけど）のも、ひとつの解決策だと思う。
正直、これ以上は答えが出ない様な気もするな。
どこまで行っても見出しは見出しだから、という意味では
杓子定規にやればそうなると思う。
ただ、確実に不都合が存在していて、
それに対する解決策が見出せていない現状では、
>>320のいう「コンセンサスがない」というのも理解出来るから、
それを避ける（避け方は色々あるだろうけど）のも、ひとつの解決策だと思う。
正直、これ以上は答えが出ない様な気もするな。
>ホームページ制作王
一応真面目に調べて見たものの、話にならない。
このスレでオーサリングツール薦めるなら、最低限「正しいHTML目指す姿勢は
評価できるなぁ…」程度の印象を与えるような物にしてほしいだが。
一応真面目に調べて見たものの、話にならない。
このスレでオーサリングツール薦めるなら、最低限「正しいHTML目指す姿勢は
評価できるなぁ…」程度の印象を与えるような物にしてほしいだが。
>>326
>ただ、確実に不都合が存在していて、
だから、>>324 で、不都合は存在しない、って書いているつもりなんだが。
例えば>>303 の指摘する見出しを抜き出してリストを作るとき問題だと言う話は、
引用中の見出しをそういう用途で抜き出す方が(HTMLだろうが、普通の紙の文書だろうが)変。
HTML仕様とかコンセンサスとか言う問題ではなく、引用を含む文書の編集の処理方法の問題。
>ただ、確実に不都合が存在していて、
だから、>>324 で、不都合は存在しない、って書いているつもりなんだが。
例えば>>303 の指摘する見出しを抜き出してリストを作るとき問題だと言う話は、
引用中の見出しをそういう用途で抜き出す方が(HTMLだろうが、普通の紙の文書だろうが)変。
HTML仕様とかコンセンサスとか言う問題ではなく、引用を含む文書の編集の処理方法の問題。
329 ：Name_Not_Found：02/04/26 01:29 ID:Zw1kiVXn
ゲイツも驚くサポートの短さだな！(ﾜﾗ
> 用文の中に出現する見出しが、通常の本文と異なり、例えば
> 見出しリストを作るときに抽出対象にすると不都合が起こる、という事は、
> HTML とかマークアップ以前の「引用」という部分で自明のことと思われるが？
でも、blockquote の中にはイレギュラーな h1-h6 を書いて良いと言うのなら、
>>303 に書いたように「blockquote 内のみならず、他の要素内でもそういう
h1-h6 を書いて良い」ことになってしまうだろ。
特殊なクラスを指定した div とか。そういうのには対応のしようがない。
HTML 4.01 系の HTML で blockquote 内に h1-h6 が認められるのは、
引用内の見出しを想定したからではなく、
単に h1-h6 が %block.mix; が含まれていたから、と考えるのが妥当と思われ。
> 見出しリストを作るときに抽出対象にすると不都合が起こる、という事は、
> HTML とかマークアップ以前の「引用」という部分で自明のことと思われるが？
でも、blockquote の中にはイレギュラーな h1-h6 を書いて良いと言うのなら、
>>303 に書いたように「blockquote 内のみならず、他の要素内でもそういう
h1-h6 を書いて良い」ことになってしまうだろ。
特殊なクラスを指定した div とか。そういうのには対応のしようがない。
HTML 4.01 系の HTML で blockquote 内に h1-h6 が認められるのは、
引用内の見出しを想定したからではなく、
単に h1-h6 が %block.mix; が含まれていたから、と考えるのが妥当と思われ。
332 ：Name_Not_Found：02/04/26 09:48 ID:b/9YPsIu
どの仕様について話をしているのか小一時間問い詰めたい。
HTML4 はイレギュラーな見出しを「書いて良い」仕様だよ。
「よくないと考える人もいる」程度の注記があるだけ。禁止していない。
だから blockquote 内に見出しを書けるんだよ。
仕様で禁止しているのは ISO-HTML だ。
ISO-HTML は見出しは body 直下にしか置けないから、はじめからそんな問題は起こらない。
何故そこだけ仕様書が違うんだ？
複数の仕様を部分的に適用すればそりゃ矛盾も出るよ。
このスレで「Strict 的」ってよく聞くけど、一体何？
無形の不思議仕様について是非を議論してないか？
HTML4 はイレギュラーな見出しを「書いて良い」仕様だよ。
「よくないと考える人もいる」程度の注記があるだけ。禁止していない。
だから blockquote 内に見出しを書けるんだよ。
仕様で禁止しているのは ISO-HTML だ。
ISO-HTML は見出しは body 直下にしか置けないから、はじめからそんな問題は起こらない。
何故そこだけ仕様書が違うんだ？
複数の仕様を部分的に適用すればそりゃ矛盾も出るよ。
このスレで「Strict 的」ってよく聞くけど、一体何？
無形の不思議仕様について是非を議論してないか？
333 ：Name_Not_Found：02/04/26 10:28 ID:l0X4yv8n
>>332
>どの仕様について話をしているのか小一時間問い詰めたい。
同意。仕様の話をするときはどのHTMLか限定しないと
不毛になると思われ。
>Strict 的
これはあくまで理念の問題であって、
直接仕様とは絡まない部分の範囲で使う言葉では。
>どの仕様について話をしているのか小一時間問い詰めたい。
同意。仕様の話をするときはどのHTMLか限定しないと
不毛になると思われ。
>Strict 的
これはあくまで理念の問題であって、
直接仕様とは絡まない部分の範囲で使う言葉では。
334 ：Name_Not_Found：02/04/26 14:18 ID:xkMVo+ev
>>332
「仕様的に OK だから」では>>320 のいう通りに
「こういう議論自体が無意味」になってしまう。
書けるとかそういう問題ではない。
>>333
これだけ問題点が指摘されているのに、
事実上、ISO-HTML については議論の対象ではないと思う。
XHTML1.1 は多少毛色が違うけど、
HTML 4.01 Strict, XHTML 1.0 Strict 辺りが議論の対象で、
そこらは暗黙の了解があるかと。
まあ、マークアップ言語の話をしていて、
「暗黙の了解」は矛盾だというツッコミは無しで。
「仕様的に OK だから」では>>320 のいう通りに
「こういう議論自体が無意味」になってしまう。
書けるとかそういう問題ではない。
>>333
これだけ問題点が指摘されているのに、
事実上、ISO-HTML については議論の対象ではないと思う。
XHTML1.1 は多少毛色が違うけど、
HTML 4.01 Strict, XHTML 1.0 Strict 辺りが議論の対象で、
そこらは暗黙の了解があるかと。
まあ、マークアップ言語の話をしていて、
「暗黙の了解」は矛盾だというツッコミは無しで。
335 ：Name_Not_Found：02/04/26 14:42 ID:l0X4yv8n
>>334
>>1に
Strict な HTML(*)
* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
XHTML 1.1, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。
と書かれている以上、
＞事実上、ISO-HTML については議論の対象ではないと思う。
は思いこみに過ぎない。
と一応ツッコミ。
>>1に
Strict な HTML(*)
* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
XHTML 1.1, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。
と書かれている以上、
＞事実上、ISO-HTML については議論の対象ではないと思う。
は思いこみに過ぎない。
と一応ツッコミ。
336 ：Name_Not_Found：02/04/26 14:59 ID:b/9YPsIu
>>333
> 直接仕様とは絡まない部分の範囲
つまり Strict の範囲外なのでは。
仕様に沿うことを言っている時もあれば、
論理 markup 全般を指して言っているように思う時もある。
markup とは無関係の件に Strict 的という言葉が使われることさえある。
「Strict 的」って、「ホームページ」と同じくらい
拡大解釈が一人歩きを始める危険性をはらんだ言葉だと思うんだよ。
「Strict 的にどうよ？」というときは、そこを抑えとかないといかんなあ、と。
>>334
>「こういう議論自体が無意味」になってしまう。
無意味だと感じたんだよ、俺。
実際の HTML4 仕様原文は下記だ。
http://www.w3.org/TR/html401/struct/global.html#h-7.5.5
> There are six levels of headings in HTML with H1 as the most important and H6 as the least.
"most important" の H1 と "the least" の H6。
HTML4/XHTML1.0 Strict での見出しレベルは階層構造の上下ではなく重要度の上下だと思う。
> 直接仕様とは絡まない部分の範囲
つまり Strict の範囲外なのでは。
仕様に沿うことを言っている時もあれば、
論理 markup 全般を指して言っているように思う時もある。
markup とは無関係の件に Strict 的という言葉が使われることさえある。
「Strict 的」って、「ホームページ」と同じくらい
拡大解釈が一人歩きを始める危険性をはらんだ言葉だと思うんだよ。
「Strict 的にどうよ？」というときは、そこを抑えとかないといかんなあ、と。
>>334
>「こういう議論自体が無意味」になってしまう。
無意味だと感じたんだよ、俺。
実際の HTML4 仕様原文は下記だ。
http://www.w3.org/TR/html401/struct/global.html#h-7.5.5
> There are six levels of headings in HTML with H1 as the most important and H6 as the least.
"most important" の H1 と "the least" の H6。
HTML4/XHTML1.0 Strict での見出しレベルは階層構造の上下ではなく重要度の上下だと思う。
337 ：Name_Not_Found：02/04/26 15:15 ID:l0X4yv8n
>>336
＞「Strict 的」って、「ホームページ」と同じくらい
＞拡大解釈が一人歩きを始める危険性をはらんだ言葉だと思うんだよ。
＞「Strict 的にどうよ？」というときは、そこを抑えとかないといかんなあ、と。
「現状の仕様的に許される方法はいろいろあるけど、
W3CがHTMLというマークアップ言語をどうして行きたいのかと言う意図を汲んだら、
またはW3Cが推奨するマークアップをするならどうよ？」＝「Strict 的にどうよ？」
と思うのだが。Webドキュメント全般の話にまで広げることもなくはない。
W3C信者的にどうよ？と言い換えた方が適切か。
＞「Strict 的」って、「ホームページ」と同じくらい
＞拡大解釈が一人歩きを始める危険性をはらんだ言葉だと思うんだよ。
＞「Strict 的にどうよ？」というときは、そこを抑えとかないといかんなあ、と。
「現状の仕様的に許される方法はいろいろあるけど、
W3CがHTMLというマークアップ言語をどうして行きたいのかと言う意図を汲んだら、
またはW3Cが推奨するマークアップをするならどうよ？」＝「Strict 的にどうよ？」
と思うのだが。Webドキュメント全般の話にまで広げることもなくはない。
W3C信者的にどうよ？と言い換えた方が適切か。
なんか書いてること矛盾してるかも。
ちょっと逝って来る。
ちょっと逝って来る。
339 ：茶文字 ◆xELvisFU ：02/04/26 16:59 ID:26ibIwYj
＞Strict的
大前提として、先に文章が存在して、適切なマークアップがなされていくわけで。
語感としては「文章に対して(能動的に)マークアップする」というよりも
「文章があれば自ずとマークアップが『発生する』」もんだと思う。
我々が手書きで文章を書く場合、見出しはよほどのことがない限り 大 -> 小 の序列を持っている。
だから仕様書はいきなり h3 から書き始められるとしても、
元の文章を書くという観点からするとそれは不自然なマークアップだ。
hn に限っていえば、見出しがある限り h1 は自ずと発生するものであり、
その下位段落に相対的に h2 以下が発生するはず。
結果的に hn は階層構造になるはず。
重要度は文脈に依存するので、 <h2 class="important"> とか
<h2 class="note"> とかで意思表示するべきだと思う。
大前提として、先に文章が存在して、適切なマークアップがなされていくわけで。
語感としては「文章に対して(能動的に)マークアップする」というよりも
「文章があれば自ずとマークアップが『発生する』」もんだと思う。
我々が手書きで文章を書く場合、見出しはよほどのことがない限り 大 -> 小 の序列を持っている。
だから仕様書はいきなり h3 から書き始められるとしても、
元の文章を書くという観点からするとそれは不自然なマークアップだ。
hn に限っていえば、見出しがある限り h1 は自ずと発生するものであり、
その下位段落に相対的に h2 以下が発生するはず。
結果的に hn は階層構造になるはず。
重要度は文脈に依存するので、 <h2 class="important"> とか
<h2 class="note"> とかで意思表示するべきだと思う。
340 ：茶文字 ◆xELvisFU ：02/04/26 17:22 ID:Zg9e2OkI
追記。
HTMLは自然言語のニュアンスをUAを通じて閲覧者に伝達するためにあるわけで、
仕様書に曖昧だったり雑な部分があるのは、自然言語の文法の曖昧さ加減や
雑さ加減に配慮したものなのかも知れない（ｗ
自然言語には文語と口語があるけど、不思議マークアップは発想が口語的。
書き言葉では必要な全体の構成や段落の適切な配置が、あまり意識されない。
日常会話では「あ、さっき言い忘れたけど」とか、段落を超えて話が飛躍することも多い。
<h1>ブロードバンド時代とStrict</h1>
<h3>xDSLとFTTHが各家庭に普及</h3>
<h3>Webのマルチメディア化が進展</h3>
<h3>MIDI厨やFlash厨が激増</h3>
<h2>(ﾟдﾟ)ﾏｽﾞｰ</h2>
口語的にはこんな感じでしゃべるのはありだろうけど、
<h1>ブロードバンド時代とStrict</h1>
<h2 class="process">xDSLとFTTHが各家庭に普及</h2>
<h2 class="process">Webのマルチメディア化が進展</h2>
<h2 class="process">MIDI厨やFlash厨が激増</h2>
<h2 class="result">(ﾟдﾟ)ﾏｽﾞｰ</h2>
文語的にはこういう感じであるべきなのではないかと。
HTMLは活字なんだから、極力文語であることを意識しようぜ、というのが
ある意味「Strict的」な発想なんじゃないか、と思う。
HTMLは自然言語のニュアンスをUAを通じて閲覧者に伝達するためにあるわけで、
仕様書に曖昧だったり雑な部分があるのは、自然言語の文法の曖昧さ加減や
雑さ加減に配慮したものなのかも知れない（ｗ
自然言語には文語と口語があるけど、不思議マークアップは発想が口語的。
書き言葉では必要な全体の構成や段落の適切な配置が、あまり意識されない。
日常会話では「あ、さっき言い忘れたけど」とか、段落を超えて話が飛躍することも多い。
<h1>ブロードバンド時代とStrict</h1>
<h3>xDSLとFTTHが各家庭に普及</h3>
<h3>Webのマルチメディア化が進展</h3>
<h3>MIDI厨やFlash厨が激増</h3>
<h2>(ﾟдﾟ)ﾏｽﾞｰ</h2>
口語的にはこんな感じでしゃべるのはありだろうけど、
<h1>ブロードバンド時代とStrict</h1>
<h2 class="process">xDSLとFTTHが各家庭に普及</h2>
<h2 class="process">Webのマルチメディア化が進展</h2>
<h2 class="process">MIDI厨やFlash厨が激増</h2>
<h2 class="result">(ﾟдﾟ)ﾏｽﾞｰ</h2>
文語的にはこういう感じであるべきなのではないかと。
HTMLは活字なんだから、極力文語であることを意識しようぜ、というのが
ある意味「Strict的」な発想なんじゃないか、と思う。
341 ：308：02/04/26 17:40 ID:mtu5f3Wj
個人的には、「のぞましいマークアップ」（情報の利用性やアクセシビリティの
見地から）を、「仕様の範囲内」で実現するための方法や考え方を論じるべきだ
と思っております。
それを便宜上「Strict的」と呼ぶのだと勝手に思ってたのですが。
見地から）を、「仕様の範囲内」で実現するための方法や考え方を論じるべきだ
と思っております。
それを便宜上「Strict的」と呼ぶのだと勝手に思ってたのですが。
342 ：308：02/04/26 17:50 ID:mtu5f3Wj
>335
>> 事実上、ISO-HTML については議論の対象ではないと思う。
> は思いこみに過ぎない。
もしかして、今回の「blockquote内の見出し」論争（？）のみについて、
限定して言ってるのでは？
そもそもblockquote内に見出しを書けないISO-HTMLではこの議論は
成立しない、という意味で。
>>340
この場合、「文語」ではなく「文章語」と言ふべきであらう。
と、野嵜氏が見たらツッコミ入れそうなところ。
って、スレ違いのような気もするが、一応。
>> 事実上、ISO-HTML については議論の対象ではないと思う。
> は思いこみに過ぎない。
もしかして、今回の「blockquote内の見出し」論争（？）のみについて、
限定して言ってるのでは？
そもそもblockquote内に見出しを書けないISO-HTMLではこの議論は
成立しない、という意味で。
>>340
この場合、「文語」ではなく「文章語」と言ふべきであらう。
と、野嵜氏が見たらツッコミ入れそうなところ。
って、スレ違いのような気もするが、一応。
343 ：Name_Not_Found：02/04/26 18:00 ID:9pZmbD9Y
blockquoteの中に見出し要素が記述できないとなると、divの中にも見出し要素が記述できないことになりますね。
なぜなら、見出しを抽出する人は見出しが同階層にあるものとする(見出しの暗黙的な階層構造のみを利用する)わけだから。
blockquoteの中にある場合も同階層の概念でないと一概に否定するべきではない。
もちろん>>289でかまわないわけだから、ほかのコンテキストとあわせたマークアップが望まれるわけだが、見出し要素の出現自体は否定すべきものではないと思う。
なぜなら、見出しを抽出する人は見出しが同階層にあるものとする(見出しの暗黙的な階層構造のみを利用する)わけだから。
blockquoteの中にある場合も同階層の概念でないと一概に否定するべきではない。
もちろん>>289でかまわないわけだから、ほかのコンテキストとあわせたマークアップが望まれるわけだが、見出し要素の出現自体は否定すべきものではないと思う。
344 ：Name_Not_Found：02/04/26 20:31 ID:MPke1VJ+
> なぜなら、見出しを抽出する人は見出しが同階層にあるものとする(見出しの暗黙的な階層構造のみを利用する)わけだから。
何を根拠に言っているのか分かりません。
どこからそんな思考が出てきたんですか?
何を根拠に言っているのか分かりません。
どこからそんな思考が出てきたんですか?
345 ：Name_Not_Found：02/04/26 21:00 ID:b/9YPsIu
>>339-340
> 大前提として、先に文章が存在して、適切なマークアップがなされていくわけで。
でもその文章にとって HTML が適切な文書型であるとは限らない。
マークアップに悩んでいるケースの大半がこれのような気がするんだよ。
それでも HTML を選ぶ動機が閲覧環境が普及しているからとか
W3C によって標準化された文書型がないからとかいう理由であれば、
それは PDF でやった方がいいことを Transitional でやるのと同じだ。
> 結果的に hn は階層構造になるはず。
この点について俺は懐疑的なんだ。
見出しが階層構造を持っている文章と Strict と、何の関係があるんだ？
HTML は HyperText Markup Language の略だが
HyperText というものを調べれば調べるほど
「人間の思考の非線形性」みたいな文章が出てくる。調べ方に問題あるのかな。
俺はますます混乱してわからなくなっている。
> 大前提として、先に文章が存在して、適切なマークアップがなされていくわけで。
でもその文章にとって HTML が適切な文書型であるとは限らない。
マークアップに悩んでいるケースの大半がこれのような気がするんだよ。
それでも HTML を選ぶ動機が閲覧環境が普及しているからとか
W3C によって標準化された文書型がないからとかいう理由であれば、
それは PDF でやった方がいいことを Transitional でやるのと同じだ。
> 結果的に hn は階層構造になるはず。
この点について俺は懐疑的なんだ。
見出しが階層構造を持っている文章と Strict と、何の関係があるんだ？
HTML は HyperText Markup Language の略だが
HyperText というものを調べれば調べるほど
「人間の思考の非線形性」みたいな文章が出てくる。調べ方に問題あるのかな。
俺はますます混乱してわからなくなっている。
346 ：茶文字 ◆xELvisFU ：02/04/26 21:20 ID:Zg9e2OkI
> >>339-340
> > 大前提として、先に文章が存在して、適切なマークアップがなされていくわけで。
> でもその文章にとって HTML が適切な文書型であるとは限らない。
> マークアップに悩んでいるケースの大半がこれのような気がするんだよ。
確かにそうだけど、マークアップの悩みはむしろ紙媒体や電波媒体などの
他のメディアのメタファとしてWebを捉えているから発生している面が大きいんじゃないかな。
プレーンテキストの文書同士を Hyper Link するというのが、
HTMLの原始的な姿だったのではないかと思う。
だから、別メディアにあるものをHTMLで再提示するのであれば、
一度プレーンテキストに落としたものをマークアップし直すのがよいと思う。
これができない情報は、少なくともHTMLで表現するのには向いてないのかも知れない。
> > 結果的に hn は階層構造になるはず。
> この点について俺は懐疑的なんだ。
> 見出しが階層構造を持っている文章と Strict と、何の関係があるんだ？
見出しが階層構造を持たない、つまり重要度の差はあれ平坦な構造をしているとしたら、
それこそすべて h1 でマークアップした上でそれぞれに class で役割を与えては？
……ってそういう意味じゃなく？
> > 大前提として、先に文章が存在して、適切なマークアップがなされていくわけで。
> でもその文章にとって HTML が適切な文書型であるとは限らない。
> マークアップに悩んでいるケースの大半がこれのような気がするんだよ。
確かにそうだけど、マークアップの悩みはむしろ紙媒体や電波媒体などの
他のメディアのメタファとしてWebを捉えているから発生している面が大きいんじゃないかな。
プレーンテキストの文書同士を Hyper Link するというのが、
HTMLの原始的な姿だったのではないかと思う。
だから、別メディアにあるものをHTMLで再提示するのであれば、
一度プレーンテキストに落としたものをマークアップし直すのがよいと思う。
これができない情報は、少なくともHTMLで表現するのには向いてないのかも知れない。
> > 結果的に hn は階層構造になるはず。
> この点について俺は懐疑的なんだ。
> 見出しが階層構造を持っている文章と Strict と、何の関係があるんだ？
見出しが階層構造を持たない、つまり重要度の差はあれ平坦な構造をしているとしたら、
それこそすべて h1 でマークアップした上でそれぞれに class で役割を与えては？
……ってそういう意味じゃなく？
347 ：Name_Not_Found：02/04/26 21:21 ID:mouaR445
「人間の思考の非線形性」も分からないのに、
HTMLを語るな。
HTMLを語るな。
>>345
>HyperText というものを調べれば調べるほど
>「人間の思考の非線形性」みたいな文章が出てくる。調べ方に問題あるのかな。
>俺はますます混乱してわからなくなっている。
裏付けのない全くの「俺の解釈」なのだが、
複数文書を関係付ける段階では、確かにHyperTextは参照元と参照先の文書を
パッチワークの様に非線形で跳躍したものにするが、参照の対象となる個々の
独立した文書の内容は、当然（万人向けに情報を伝達する為には既知から未知へ
段階的に順を追って情報を伝えねばならないのだから）線形になる…筈だ。
従って、一つの（単独で読まれることを考慮した） HTML Document を
製作する段階としてマークアップが語られる場合、それは、既存の論文と
何ら変わらない線形の文書構造を有した物である事を前提にすると思うのだが、
どうだろうか。
＃単独で機能しないことを前提とした、例えばリンク集などは非線形の文書に
なって当然と思う。例えば、分類学的な整理より、利用者の巡回経路に
あわせて整理されたリンクリストの方が一般的には使い勝手がよい。
>HyperText というものを調べれば調べるほど
>「人間の思考の非線形性」みたいな文章が出てくる。調べ方に問題あるのかな。
>俺はますます混乱してわからなくなっている。
裏付けのない全くの「俺の解釈」なのだが、
複数文書を関係付ける段階では、確かにHyperTextは参照元と参照先の文書を
パッチワークの様に非線形で跳躍したものにするが、参照の対象となる個々の
独立した文書の内容は、当然（万人向けに情報を伝達する為には既知から未知へ
段階的に順を追って情報を伝えねばならないのだから）線形になる…筈だ。
従って、一つの（単独で読まれることを考慮した） HTML Document を
製作する段階としてマークアップが語られる場合、それは、既存の論文と
何ら変わらない線形の文書構造を有した物である事を前提にすると思うのだが、
どうだろうか。
＃単独で機能しないことを前提とした、例えばリンク集などは非線形の文書に
なって当然と思う。例えば、分類学的な整理より、利用者の巡回経路に
あわせて整理されたリンクリストの方が一般的には使い勝手がよい。
349 ：茶文字 ◆xELvisFU ：02/04/26 21:46 ID:5jcGdH79
hnについて。
仕様書には h1 がもっとも重要な見出しを示し、h6 はその反対と書いてあるわけだが、
文脈上の重要度だけを根拠にマークアップすると、たとえ文書冒頭にあっても
「このセクションは全体から見て重要ではないから、h4 から始めよう」ということが可能だ。
で、DTDには反していないから valid ではある。
が、正規のHTMLは文書型宣言とHTMLの開始タグから始まりHTMLの終了タグで終わる。
# もちろん必要に応じてxml宣言もありだが。
これを考えると、HTMLは単一文書内でマークアップとして完結している必要がある。
つまり、他の文書との相対的な重要度でマークアップが左右されてはいけないのではないか。
他の文書との関連性を示すには link要素が使われるべきであって、
続き物のコンテンツであってもよそから直接参照される可能性があるのが
HTMLの特徴であり利点なわけで(このあたりが思考の非線形性の具体化された部分でもある)、
単独で見たときに意図がつかめないマークアップはするべきではない。
で、hn が相対的なものだとしても、デフォルトが h1 で以下相対的に
h2～h6 が下位に配置できるということだと思う。
つまり、h1 が存在しない文書や h2 を飛び越して h3 が配置された文書はおかしい。
まとまりない長文でｽﾏｿ
仕様書には h1 がもっとも重要な見出しを示し、h6 はその反対と書いてあるわけだが、
文脈上の重要度だけを根拠にマークアップすると、たとえ文書冒頭にあっても
「このセクションは全体から見て重要ではないから、h4 から始めよう」ということが可能だ。
で、DTDには反していないから valid ではある。
が、正規のHTMLは文書型宣言とHTMLの開始タグから始まりHTMLの終了タグで終わる。
# もちろん必要に応じてxml宣言もありだが。
これを考えると、HTMLは単一文書内でマークアップとして完結している必要がある。
つまり、他の文書との相対的な重要度でマークアップが左右されてはいけないのではないか。
他の文書との関連性を示すには link要素が使われるべきであって、
続き物のコンテンツであってもよそから直接参照される可能性があるのが
HTMLの特徴であり利点なわけで(このあたりが思考の非線形性の具体化された部分でもある)、
単独で見たときに意図がつかめないマークアップはするべきではない。
で、hn が相対的なものだとしても、デフォルトが h1 で以下相対的に
h2～h6 が下位に配置できるということだと思う。
つまり、h1 が存在しない文書や h2 を飛び越して h3 が配置された文書はおかしい。
まとまりない長文でｽﾏｿ
350 ：Name_Not_Found：02/04/26 22:28 ID:b/9YPsIu
>>346
> それこそすべて h1 でマークアップした上でそれぞれに class で役割を与えては？
class は具体的な役割を与えることはできない。
「何かの役割が与えられている」ということを表せるだけ。
それが Strict な文書かと聞けば、やっぱり意見が割れるような気がする。
>>348
> 参照の対象となる個々の独立した文書の内容は、(中略) 線形になる…筈だ。
では、線形の内容をもつ文書の一部分にリンクするような
部分識別子によるリンクはあまり望ましくない？
また link rel="next" のような順に読むことを想定する文書群は
予め一つのファイルにする方がよいのだろうか。
>>349
> つまり、h1 が存在しない文書や h2 を飛び越して h3 が配置された文書はおかしい。
その立場では、 h4, h2, h1, h3, と続くような文書は、どうなの？
> それこそすべて h1 でマークアップした上でそれぞれに class で役割を与えては？
class は具体的な役割を与えることはできない。
「何かの役割が与えられている」ということを表せるだけ。
それが Strict な文書かと聞けば、やっぱり意見が割れるような気がする。
>>348
> 参照の対象となる個々の独立した文書の内容は、(中略) 線形になる…筈だ。
では、線形の内容をもつ文書の一部分にリンクするような
部分識別子によるリンクはあまり望ましくない？
また link rel="next" のような順に読むことを想定する文書群は
予め一つのファイルにする方がよいのだろうか。
>>349
> つまり、h1 が存在しない文書や h2 を飛び越して h3 が配置された文書はおかしい。
その立場では、 h4, h2, h1, h3, と続くような文書は、どうなの？
351 ：茶文字 ◆xELvisFU ：02/04/26 22:45 ID:5jcGdH79
>>350
＞ それが Strict な文書かと聞けば、やっぱり意見が割れるような気がする。
役割を明確にするために目立たせたりひっこめたりするのはCSSの任務じゃない？
現状のHTMLでは
<h2><strong>これが大事だ！</strong></h2>
とか
<h3><code>foreach <var>変数</var>(条件式)</code></h3>
などのマークアップが精一杯だし、逆に言えばこのあたりの制約の多さが
HTMLを簡素化しているし見通しもよくしている(個々の不満はあるにせよ)。
で、このあたりを補うのにclassやidが用いられるのは間違ってはいないと思う。
＞ > つまり、h1 が存在しない文書や h2 を飛び越して h3 が配置された文書はおかしい。
＞ その立場では、 h4, h2, h1, h3, と続くような文書は、どうなの？
そりゃおかしいのでは？
というか、そういうマークアップに必然性のある文書ってどんなものがある？
＞ それが Strict な文書かと聞けば、やっぱり意見が割れるような気がする。
役割を明確にするために目立たせたりひっこめたりするのはCSSの任務じゃない？
現状のHTMLでは
<h2><strong>これが大事だ！</strong></h2>
とか
<h3><code>foreach <var>変数</var>(条件式)</code></h3>
などのマークアップが精一杯だし、逆に言えばこのあたりの制約の多さが
HTMLを簡素化しているし見通しもよくしている(個々の不満はあるにせよ)。
で、このあたりを補うのにclassやidが用いられるのは間違ってはいないと思う。
＞ > つまり、h1 が存在しない文書や h2 を飛び越して h3 が配置された文書はおかしい。
＞ その立場では、 h4, h2, h1, h3, と続くような文書は、どうなの？
そりゃおかしいのでは？
というか、そういうマークアップに必然性のある文書ってどんなものがある？
>>350
>class は具体的な役割を与えることはできない。
（中略）
>それが Strict な文書かと聞けば、やっぱり意見が割れるような気がする。
基本的には同意するが、少なくとも class をつけなかったり、
マークアップしなかったり、又は全然別の要素でマークアップするより
strict だとは思う。
例えばh1-h6 のレベルに当てはまらないが、しかし、文書構造上「見出し」のhoge
をマークアップする場合、<div class="hoge">hoge</div>より<h1 class="hoge">hoge</h1>
の方がstrict 的にはベター。
また、どうしても既存のDTDにない要素を明示する必要性がある場合は、
XHTML で文書を作成し、その中に独自の要素を定義したDTDを名前空間を使って
挿入する、という方法を既に W3C は提供している。
>順に読むことを想定する文書群は予め一つのファイルにする方がよいのだろうか
ファイルの転送速度やら、DOMなどの処理時の要素数を考慮した分断が
原因であれば、その原因が取り除かれ次第一つにした方が良いと思う。
が、例えば「１．足し算」「２．引き算」「３．掛け算」という文書なら
それぞれ独立文書として分けたほうが良い筈。
>その立場では、 h4, h2, h1, h3, と続くような文書は、どうなの？
申し訳ないが、h１から並べなおすと、それが改悪になるような文章というのが
想像できないので、例示して欲しい。
>>351
>役割を明確にするために目立たせたりひっこめたりするのはCSSの任務じゃない
CSS は役割を表示するときの表示手法であって、あくまで HTML はCSSと独立して
存在しえるべき。
その他の部分に関しては激しく同意。
>>329
今更だが、スマソ。
>class は具体的な役割を与えることはできない。
（中略）
>それが Strict な文書かと聞けば、やっぱり意見が割れるような気がする。
基本的には同意するが、少なくとも class をつけなかったり、
マークアップしなかったり、又は全然別の要素でマークアップするより
strict だとは思う。
例えばh1-h6 のレベルに当てはまらないが、しかし、文書構造上「見出し」のhoge
をマークアップする場合、<div class="hoge">hoge</div>より<h1 class="hoge">hoge</h1>
の方がstrict 的にはベター。
また、どうしても既存のDTDにない要素を明示する必要性がある場合は、
XHTML で文書を作成し、その中に独自の要素を定義したDTDを名前空間を使って
挿入する、という方法を既に W3C は提供している。
>順に読むことを想定する文書群は予め一つのファイルにする方がよいのだろうか
ファイルの転送速度やら、DOMなどの処理時の要素数を考慮した分断が
原因であれば、その原因が取り除かれ次第一つにした方が良いと思う。
が、例えば「１．足し算」「２．引き算」「３．掛け算」という文書なら
それぞれ独立文書として分けたほうが良い筈。
>その立場では、 h4, h2, h1, h3, と続くような文書は、どうなの？
申し訳ないが、h１から並べなおすと、それが改悪になるような文章というのが
想像できないので、例示して欲しい。
>>351
>役割を明確にするために目立たせたりひっこめたりするのはCSSの任務じゃない
CSS は役割を表示するときの表示手法であって、あくまで HTML はCSSと独立して
存在しえるべき。
その他の部分に関しては激しく同意。
>>329
今更だが、スマソ。
353 ：Name_Not_Found：02/04/26 23:16 ID:b/9YPsIu
> 役割を明確にするために目立たせたりひっこめたりするのはCSSの任務じゃない？
CSS がなければ役割を明確にできないということ？
> そりゃおかしいのでは？
> というか、そういうマークアップに必然性のある文書ってどんなものがある？
例が極端すぎたかな。ちょっと前に出てた >>238-243 あたりとか。
あれって h1, h2, h4 を禁止してしまっているから出てくる話だ。
W3C のトップページの h1-h3は、見出しレベルが飛んでこそいないけれど
階層構造を全然表さない見出しレベルが使われている。
あれはよろしくないのか？ Transitional だから OK なのか？
CSS がなければ役割を明確にできないということ？
> そりゃおかしいのでは？
> というか、そういうマークアップに必然性のある文書ってどんなものがある？
例が極端すぎたかな。ちょっと前に出てた >>238-243 あたりとか。
あれって h1, h2, h4 を禁止してしまっているから出てくる話だ。
W3C のトップページの h1-h3は、見出しレベルが飛んでこそいないけれど
階層構造を全然表さない見出しレベルが使われている。
あれはよろしくないのか？ Transitional だから OK なのか？
>>353
>ちょっと前に出てた >>238-243 あたりとか。
>あれって h1, h2, h4 を禁止してしまっているから出てくる話だ。
正にその最後の部分の >>243-244 で一応俺の意見は述べているが、
今の論議にあわせて、改めて言わせてもらえば
>>238 の件は
１：本当はどこかに隠れた分類上の見出しがある。
２：同一レベルのない様に思えるが分類上はネストの深さが違うので、
見出しレベルが異なる方が寧ろ相当。
のどちらかになると思われる。つまり、問題ない。
>W3C のトップページの h1-h3は、見出しレベルが飛んでこそいないけれど
>階層構造を全然表さない見出しレベルが使われている。
>あれはよろしくないのか？ Transitional だから OK なのか？
W3C は自身のWebSiteをstrictより、実装重視でマークアップしているだけかと。
というわけで、strict的には例えW3Cのマークアップだろうとも、「よろしくない」。
ついでに言えば、transitional だからといってtableでレイアウトが許容
されるとは仕様の何処にも書いていないので、仕様第一主義ならtransitionalであってもNG。
>ちょっと前に出てた >>238-243 あたりとか。
>あれって h1, h2, h4 を禁止してしまっているから出てくる話だ。
正にその最後の部分の >>243-244 で一応俺の意見は述べているが、
今の論議にあわせて、改めて言わせてもらえば
>>238 の件は
１：本当はどこかに隠れた分類上の見出しがある。
２：同一レベルのない様に思えるが分類上はネストの深さが違うので、
見出しレベルが異なる方が寧ろ相当。
のどちらかになると思われる。つまり、問題ない。
>W3C のトップページの h1-h3は、見出しレベルが飛んでこそいないけれど
>階層構造を全然表さない見出しレベルが使われている。
>あれはよろしくないのか？ Transitional だから OK なのか？
W3C は自身のWebSiteをstrictより、実装重視でマークアップしているだけかと。
というわけで、strict的には例えW3Cのマークアップだろうとも、「よろしくない」。
ついでに言えば、transitional だからといってtableでレイアウトが許容
されるとは仕様の何処にも書いていないので、仕様第一主義ならtransitionalであってもNG。
355 ：茶文字 ◆xELvisFU ：02/04/26 23:52 ID:5jcGdH79
>>352-353
hnが階層構造をなすという仮定で書いてきたけど、
現状 hn では6階層の見出ししかマークアップできない。
h1 を基点とした相対的な重要度しか与えることができないから、
このあたりがHTMLの限界ではある。
で、手薄な部分を補うためには class や id に頼らざるを得ないのではないかと。
先に挙げた例で言えば、
1.<h2><strong>これが重要！</strong></h2>
2.<h2 class="strong">これが重要！</h2>
上記のどちらがよりStrict的か、という話にもなる。
1.はソースの見通しがやや悪く、2.はCSSオフの状態では
(現行UAは)当該セクションの位置づけを明確に表示できない。
CSSがなくても位置づけが明確になることが理想だとすると、2.の方が適切なのかな。
>>353後半については、>>239で一例を挙げたように
div 内の見出しを h1 から振り直すことで一応の階層構造を維持できる。
# これもCSSオフの状態では表示上厳しいが。
CSSオフで class/id で与えた役割が伝えられないのも、
現行HTMLの欠点と言えるだろうしUAの未成熟とも言える。
# UAについては、たとえばclass/id をツールチップで表示するなどの方法があっていい。
でも、代表的な視覚系UAの表示に立脚して述べるのは、少なくともStrict的ではないだろうね。
hnが階層構造をなすという仮定で書いてきたけど、
現状 hn では6階層の見出ししかマークアップできない。
h1 を基点とした相対的な重要度しか与えることができないから、
このあたりがHTMLの限界ではある。
で、手薄な部分を補うためには class や id に頼らざるを得ないのではないかと。
先に挙げた例で言えば、
1.<h2><strong>これが重要！</strong></h2>
2.<h2 class="strong">これが重要！</h2>
上記のどちらがよりStrict的か、という話にもなる。
1.はソースの見通しがやや悪く、2.はCSSオフの状態では
(現行UAは)当該セクションの位置づけを明確に表示できない。
CSSがなくても位置づけが明確になることが理想だとすると、2.の方が適切なのかな。
>>353後半については、>>239で一例を挙げたように
div 内の見出しを h1 から振り直すことで一応の階層構造を維持できる。
# これもCSSオフの状態では表示上厳しいが。
CSSオフで class/id で与えた役割が伝えられないのも、
現行HTMLの欠点と言えるだろうしUAの未成熟とも言える。
# UAについては、たとえばclass/id をツールチップで表示するなどの方法があっていい。
でも、代表的な視覚系UAの表示に立脚して述べるのは、少なくともStrict的ではないだろうね。
356 ：Name_Not_Found：02/04/26 23:54 ID:b/9YPsIu
>>354
見出しの重要度をネストの深さとみなせる根拠は何？暗黙の了解か？
その部分で、HTML4 Strict にないものを
他所から持ってきて勝手に組み込んでしまっていないか？
それは既に Strict とは別の何かじゃないのか？
見出しの重要度をネストの深さとみなせる根拠は何？暗黙の了解か？
その部分で、HTML4 Strict にないものを
他所から持ってきて勝手に組み込んでしまっていないか？
それは既に Strict とは別の何かじゃないのか？
>>356
>見出しの重要度をネストの深さとみなせる根拠は何？暗黙の了解か？
>>238 が
>分類内の小分類の有無によって
>あるタグは h3 だけど別なタグは h4、という場面が出てきて、なんか気持ち悪い。
と述べているので、俺は「小分類の有無によって見出しレベルが分かれるのが相当な文書」の
HTMLによるマークアップ法について語っていますが何か？
>見出しの重要度をネストの深さとみなせる根拠は何？暗黙の了解か？
>>238 が
>分類内の小分類の有無によって
>あるタグは h3 だけど別なタグは h4、という場面が出てきて、なんか気持ち悪い。
と述べているので、俺は「小分類の有無によって見出しレベルが分かれるのが相当な文書」の
HTMLによるマークアップ法について語っていますが何か？
358 ：Name_Not_Found：02/04/27 00:10 ID:Cz/JUHYC
>>358
マジゴメン。
テーブルレイアウトしてたり、border か outline 相当の
仕切り線をパイプで書いてたりしてるので、見出しのマークアップに関しても
勝手にいい加減なものに脳内変換してた。
ちょっと逝って詫びて来る。
マジゴメン。
テーブルレイアウトしてたり、border か outline 相当の
仕切り線をパイプで書いてたりしてるので、見出しのマークアップに関しても
勝手にいい加減なものに脳内変換してた。
ちょっと逝って詫びて来る。
360 ：Name_Not_Found：02/04/27 00:38 ID:Z5eLmoAg
> 見出しの重要度をネストの深さとみなせる根拠は何? 暗黙の了解か?
SGML 時代から10年以上続いている常識ですから、文字通り暗黙の諒解でしょう。
ISO-HTML でも構造のレベルと明言されていますし。
HTML 4.01 では「h1 + h3 のような記述を好まない人もいる」
という程度の表現に留められていますけれども。
SGML 時代から10年以上続いている常識ですから、文字通り暗黙の諒解でしょう。
ISO-HTML でも構造のレベルと明言されていますし。
HTML 4.01 では「h1 + h3 のような記述を好まない人もいる」
という程度の表現に留められていますけれども。
361 ：Name_Not_Found：02/04/27 09:25 ID:8r+VEVu9
rubyの仕様書を読んでたら、classで読み仮名なのか何なのかを区別すべき
とあったけど、意味あるのかねコレ。
UAにルビの意味を伝えるなら新しい属性を作るべきと思った。
とあったけど、意味あるのかねコレ。
UAにルビの意味を伝えるなら新しい属性を作るべきと思った。
362 ：Name_Not_Found：02/04/27 10:21 ID:55vjkGIc
>>361
用途別の属性値が何か規定されてるわけでも無し、
人がソース見たときに、用途を推測できるという以上の意味は無い。
それ以前にrubyなんてXSLにすべき物であってXHTMLに含める必要は無いと思う。
用途別の属性値が何か規定されてるわけでも無し、
人がソース見たときに、用途を推測できるという以上の意味は無い。
それ以前にrubyなんてXSLにすべき物であってXHTMLに含める必要は無いと思う。
363 ：Name_Not_Found：02/04/27 15:38 ID:ViHKn08U
>>362
> それ以前に ruby なんて XSL にすべき物であって XHTML に含める必要は無いと思う。
面白い。でも、XSL/T 使うにしても、日本語のように読みがなを漢字から
一意に特定できない場合は、何らかの形で読みがなの指定が必要になってくるんじゃないか?
<span pron="にちゃん">2ch</span> とか。
…この形で読みを示す汎用属性が定義されている方が便利かも。
でも、title をそういう風に使うこともできるか。
とは言え title は他の使われ方をすることもあるんだから、
title を直に rt に変換する訳にもいかないし…。
> それ以前に ruby なんて XSL にすべき物であって XHTML に含める必要は無いと思う。
面白い。でも、XSL/T 使うにしても、日本語のように読みがなを漢字から
一意に特定できない場合は、何らかの形で読みがなの指定が必要になってくるんじゃないか?
<span pron="にちゃん">2ch</span> とか。
…この形で読みを示す汎用属性が定義されている方が便利かも。
でも、title をそういう風に使うこともできるか。
とは言え title は他の使われ方をすることもあるんだから、
title を直に rt に変換する訳にもいかないし…。
364 ：Name_Not_Found：02/04/27 16:10 ID:SWrmUxdY
見出し要素の数字を重要度とみなすのは確かに合理的だが、見出し要素はUAが目次に抽出してよいと仕様書に規定されているように、慣用的に階層構造とされているので、それに従うべきである。
HTMLの問題はほかの文書形式と整合性を取り、文書構造を単純にするために、見出し要素に暗黙的な階層構造を持せることで、文書構造が複雑になるのを防いだ。
その意味で、HTMLはDOMの階層よりも見出し要素の暗黙的な階層構造のほうが重視されるべきである。
しかし、XML(SGML)はDOMの階層はもちろんDOMの階層がすべてであるから、今厳密にHTMLを記述しようと思えばこの二つの階層構造がともに成立しするようにすべきである。
>>355
HTML自体では、class属性は意味を持たない。ほかのスタイルシート・プログラムと組み合わされて始めてその意味を持つ。単体では表示されるべきでない属性であり、ツールチップはtitle属性でかまわない。
>>362
振り仮名という意味で厳密に使われれば音声ブラウザにとって都合がいいんだけどな。
ところでhttp://www.w3.org/TR/html4/からLatest version of HTMLのURIへ行くとXHTML 1.0の仕様書になるね。なぜXHTML 1.1でないのだろう。
HTMLの問題はほかの文書形式と整合性を取り、文書構造を単純にするために、見出し要素に暗黙的な階層構造を持せることで、文書構造が複雑になるのを防いだ。
その意味で、HTMLはDOMの階層よりも見出し要素の暗黙的な階層構造のほうが重視されるべきである。
しかし、XML(SGML)はDOMの階層はもちろんDOMの階層がすべてであるから、今厳密にHTMLを記述しようと思えばこの二つの階層構造がともに成立しするようにすべきである。
>>355
HTML自体では、class属性は意味を持たない。ほかのスタイルシート・プログラムと組み合わされて始めてその意味を持つ。単体では表示されるべきでない属性であり、ツールチップはtitle属性でかまわない。
>>362
振り仮名という意味で厳密に使われれば音声ブラウザにとって都合がいいんだけどな。
ところでhttp://www.w3.org/TR/html4/からLatest version of HTMLのURIへ行くとXHTML 1.0の仕様書になるね。なぜXHTML 1.1でないのだろう。
365 ：Name_Not_Found：02/04/27 16:49 ID:W3RnEZ91
てかiso使いはblockquote内の
見出しをどうしているんだ？それ聞けば謎は解ける
見出しをどうしているんだ？それ聞けば謎は解ける
366 ：Name_Not_Found：02/04/27 17:17 ID:XpOrpaTr
>>364
>振り仮名という意味で厳密に使われれば
>音声ブラウザにとって都合がいいんだけどな。
rtの内容は振り仮名とは限らないし、振り仮名なのか何なのかはclassで
区別すべし、とあるだけなんだよね。
複雑ルビはどう読むんだろう？とも思うし。
>振り仮名という意味で厳密に使われれば
>音声ブラウザにとって都合がいいんだけどな。
rtの内容は振り仮名とは限らないし、振り仮名なのか何なのかはclassで
区別すべし、とあるだけなんだよね。
複雑ルビはどう読むんだろう？とも思うし。
>>364
>Latest version of HTML
たった今思いついた話なんだが、rubyのようなSGMLベースのHTMLにない要素を
HTMLとしてアリにすると、従来のHTMLブラウザでは対応が不可能になるので、
従来の(HTML4.01までの)HTMLにある要素までに限定した物がHTMLで、
XHTML1.1はHTMLから脱却した"X"HTML(not HTML)って事なんではないかと思った。
つまり、今後XHTML2.0などがリリースされ、それを「HTMLブラウザの為にXSLTでHTMLにする」と
言ったら、その「HTML」とは「(rubyなどを含まず、逆にnameなどを認める)XHTML1.0」を指す、と言う事で。
因みに、XHTML-Basicは、拡張される事を前提にした新しいXHTMLの雛型なので、
存在意義が違うので、思考から除外（ご都合主義）。
＃こんな事言っていると、また神崎氏に「勝手な解釈が横行～」とか、叱れるかも知れんが（笑）
>Latest version of HTML
たった今思いついた話なんだが、rubyのようなSGMLベースのHTMLにない要素を
HTMLとしてアリにすると、従来のHTMLブラウザでは対応が不可能になるので、
従来の(HTML4.01までの)HTMLにある要素までに限定した物がHTMLで、
XHTML1.1はHTMLから脱却した"X"HTML(not HTML)って事なんではないかと思った。
つまり、今後XHTML2.0などがリリースされ、それを「HTMLブラウザの為にXSLTでHTMLにする」と
言ったら、その「HTML」とは「(rubyなどを含まず、逆にnameなどを認める)XHTML1.0」を指す、と言う事で。
因みに、XHTML-Basicは、拡張される事を前提にした新しいXHTMLの雛型なので、
存在意義が違うので、思考から除外（ご都合主義）。
＃こんな事言っていると、また神崎氏に「勝手な解釈が横行～」とか、叱れるかも知れんが（笑）
368 ：Name_Not_Found：02/04/27 22:34 ID:W3RnEZ91
神崎氏といえば
神崎氏のように
URNに使えるpinが欲しい
どうすればいいの？
神崎氏のように
URNに使えるpinが欲しい
どうすればいいの？
369 ：Name_Not_Found：02/04/27 23:59 ID:W3RnEZ91
URN:pin:368
とすれば俺を示す
みたいな奴、頂戴。
とすれば俺を示す
みたいな奴、頂戴。
370 ：Name_Not_Found：02/04/28 01:30 ID:j9k6dzLA
>>365
野嵜氏は「見出しを含めるような引用はそれ自体が望ましくない」という意味の
ことを書いてたような気がするが、どこでそう言ってたかは忘れてしまったので
未確認。
>>366
ふりがな以外のrubyの使い方って、たとえばどんなものがありうるんでしょう。
ちょっと思いつかないので、だれか具体的な例があったら教えてください。
野嵜氏は「見出しを含めるような引用はそれ自体が望ましくない」という意味の
ことを書いてたような気がするが、どこでそう言ってたかは忘れてしまったので
未確認。
>>366
ふりがな以外のrubyの使い方って、たとえばどんなものがありうるんでしょう。
ちょっと思いつかないので、だれか具体的な例があったら教えてください。
371 ：Name_Not_Found：02/04/28 02:17 ID:lCOi4Knw
<ruby><rb>ネギ味噌ラーメン大盛り</rb><rt>いつもの</rt></ruby>
372 ：Name_Not_Found：02/04/28 09:02 ID:9A1aPjQR
>>370
確かに、いつぞや闇黒日記の中でんな事を言っていた（調べる気にもならんが）。
引用は必要最小限でなければならないから、というような論拠だったが、
見出しが必要最小限の範囲内外になるかどうかは時と場合によるし、
ISO-HTMLがそんな事を意識的にやったとも思えん。
ついでに言うと、野嵜もそんな説明に説得力があると思って言っているとも
思えん。要するにネタじゃん？
確かに、いつぞや闇黒日記の中でんな事を言っていた（調べる気にもならんが）。
引用は必要最小限でなければならないから、というような論拠だったが、
見出しが必要最小限の範囲内外になるかどうかは時と場合によるし、
ISO-HTMLがそんな事を意識的にやったとも思えん。
ついでに言うと、野嵜もそんな説明に説得力があると思って言っているとも
思えん。要するにネタじゃん？
373 ：Name_Not_Found：02/04/28 09:20 ID:fbWfKOqE
>>370
ふりがなの域を出ないかもしれんが、
<ruby><rb>光剣</rb><rt>ライトセーバー</rt></ruby>
<ruby><rb>理力</rb><rt>フォース</rt></ruby>
ふりがなの域を出ないかもしれんが、
<ruby><rb>光剣</rb><rt>ライトセーバー</rt></ruby>
<ruby><rb>理力</rb><rt>フォース</rt></ruby>
374 ：Name_Not_Found：02/04/28 09:41 ID:9A1aPjQR
>>366
>Month Day Year
> 10 31 2002
>Expiration Date
こんなん。確実に発音を表していないし、W3Cの例示なので、仕様的にもアリ。
ttp://www.w3.org/TR/2001/REC-ruby-20010531/#complex
>Month Day Year
> 10 31 2002
>Expiration Date
こんなん。確実に発音を表していないし、W3Cの例示なので、仕様的にもアリ。
ttp://www.w3.org/TR/2001/REC-ruby-20010531/#complex
375 ：Name_Not_Found：02/04/28 09:42 ID:9A1aPjQR
376 ：Name_Not_Found：02/04/28 10:09 ID:/gxzFluK
>>371も決してネタじゃなくて、アリだからなぁ。
377 ：Name_Not_Found：02/04/28 19:06 ID:5hQiGSb2
rdfファイルで
dc:type がtextなサイトのindexも<dc:type>text</dc:type>でokすかね？
あとどこあで自由あります？http://www.w3.org/TR/REC-rdf-syntax/
とか見ると結構
textやdatesetなど基本的な形以外もpoemとかvideo gameとかって値も
あるようですが、それでもstricは逸脱しませんかねえ？
いまいちうちのサイトにびしっとくるtypeの値がないもんで・・・。
dc:type がtextなサイトのindexも<dc:type>text</dc:type>でokすかね？
あとどこあで自由あります？http://www.w3.org/TR/REC-rdf-syntax/
とか見ると結構
textやdatesetなど基本的な形以外もpoemとかvideo gameとかって値も
あるようですが、それでもstricは逸脱しませんかねえ？
いまいちうちのサイトにびしっとくるtypeの値がないもんで・・・。
378 ：Name_Not_Found：02/04/28 21:31 ID:OTFV6Thd
>>376 てゆーか、371もふりがなだと思うけど。
379 ：Name_Not_Found：02/04/29 01:17 ID:a9bKZGcv
xhtml1.1のheadにprofile属性いれちゃだめなんすか？
another lintで叱られたんすけど
another lintで叱られたんすけど
380 ：Name_Not_Found：02/04/29 01:37 ID:hspJoOsk
>>379
DTDをざっと見た感じではXHTML1.1は勿論、
HTML4.01,ISO-HTML,XHTML 1.0,XHTML-Basic 1.0 と、現在メジャーなHTML/XHTML
すべて使える。lint の実装漏れかも。
DTDをざっと見た感じではXHTML1.1は勿論、
HTML4.01,ISO-HTML,XHTML 1.0,XHTML-Basic 1.0 と、現在メジャーなHTML/XHTML
すべて使える。lint の実装漏れかも。
381 ：Name_Not_Found：02/04/29 01:50 ID:3mn9t0xT
>>379-380
HTML 4.01 / XHTML 1.0 では問題ないみたい。
XHTML Basic では以前同様の警告が出ていたが修正済み。
現状で問題があるのは XHTML 1.1 だけみたいだね。
多分、xhtml-struct-1.mod の <!ATTLIST head profile CDATA '' > という
空のデフォルト値がうまく拾えていないんだと思う。
>>379 は k16 さんに教えてあげると吉。
HTML 4.01 / XHTML 1.0 では問題ないみたい。
XHTML Basic では以前同様の警告が出ていたが修正済み。
現状で問題があるのは XHTML 1.1 だけみたいだね。
多分、xhtml-struct-1.mod の <!ATTLIST head profile CDATA '' > という
空のデフォルト値がうまく拾えていないんだと思う。
>>379 は k16 さんに教えてあげると吉。
382 ：379：02/04/29 03:11 ID:a9bKZGcv
恐れ多いからやめときます。
つうか
ここ見てるんすかね
今見たらprofile属性通った。
ここ見てるんすかね
今見たらprofile属性通った。
今見たら
だめだった
いいときとだめなときがあるのね。
だめだった
いいときとだめなときがあるのね。
385 ：Name_Not_Found：02/04/29 18:20 ID:n+RFagVH
漏れが試したところではコンスタントにエラーになっているけど…。
# >>379さんが遠慮しているみたいなので、k16 さんに報告してきます。
# でも作者側の視点からは、この手のことに気付いたときは
# ためらわずに指摘してくれた方が有難いと思うYO!
# >>379さんが遠慮しているみたいなので、k16 さんに報告してきます。
# でも作者側の視点からは、この手のことに気付いたときは
# ためらわずに指摘してくれた方が有難いと思うYO!
388 ：Name_Not_Found：02/04/30 11:19 ID:0p87H+Zn
てかprofileなんか使っている人いるの？
389 ：Name_Not_Found：02/04/30 14:30 ID:nVAh8k61
>>388
神崎たん。
神崎たん。
390 ：Name_Not_Found：02/04/30 15:08 ID:T325BtQu
<hr />って物理要素だったんすか？（汗
ってことは、あまり好ましくないんでしょうか？
でも、明示的に区切りを表現するのに代替が見当たらない…。
ってことは、あまり好ましくないんでしょうか？
でも、明示的に区切りを表現するのに代替が見当たらない…。
391 ：Name_Not_Found：02/04/30 15:13 ID:CNVZ7UPn
>>390
ブロック要素の区切りをもって区切りとするのは不可ですか？
ブロック要素の区切りをもって区切りとするのは不可ですか？
392 ：Name_Not_Found：02/04/30 15:22 ID:T325BtQu
>>391
えーとつまり、
<div id="menu">
ほにゃらら
</div>
<div id="main">
ほにゃらら
</div>
で menu と main の区切りとする…ってことですか。
うーん、そうですねぇ。というか、それくらいしか方法がないですかね。
えーとつまり、
<div id="menu">
ほにゃらら
</div>
<div id="main">
ほにゃらら
</div>
で menu と main の区切りとする…ってことですか。
うーん、そうですねぇ。というか、それくらいしか方法がないですかね。
393 ：Name_Not_Found：02/04/30 15:37 ID:jVZF0ou4
とはいえ本末転倒なのはわかってるけど
それだと CSS 非対応視覚系 UA で
区切りが区切りにならないからなぁ。
正式に hr が非推奨になるまでは
あれやこれやと理屈をこね回して
使い続ける所存であります。
それだと CSS 非対応視覚系 UA で
区切りが区切りにならないからなぁ。
正式に hr が非推奨になるまでは
あれやこれやと理屈をこね回して
使い続ける所存であります。
394 ：茶文字 ◆xELviAAg ：02/04/30 15:39 ID:AIy8XnxX
>391
CSS非対応ブラウザだと見難い。
だからよくdivでborderを表示して
div hr{display:none}としてCSS非対応ブラウザに対応してる
ところとかあるね。
<div id="menu">
<hr />
</div>
CSS非対応ブラウザだと見難い。
だからよくdivでborderを表示して
div hr{display:none}としてCSS非対応ブラウザに対応してる
ところとかあるね。
<div id="menu">
<hr />
</div>
395 ：Name_Not_Found：02/04/30 15:46 ID:T325BtQu
396 ：Name_Not_Found：02/04/30 16:08 ID:53oXL1Th
「CSS 非対応視覚系 UA」なるものを考える時点で
ValidなHTMLなぞ書けないのでどうでもいいです。
ValidなHTMLなぞ書けないのでどうでもいいです。
397 ：Name_Not_Found：02/04/30 16:15 ID:sahmLPeN
>>394
氏ね。
氏ね。
398 ：Name_Not_Found：02/04/30 16:17 ID:NsCByJoH
>>396
CSSをoffにした場合とか考えてないワケ？
CSSをoffにした場合とか考えてないワケ？
399 ：Name_Not_Found：02/04/30 16:19 ID:53oXL1Th
CSSをoffにした場合＝UAデフォルトのCSSが適用される場合
と考えたらどうなる？
と考えたらどうなる？
400 ：Name_Not_Found：02/04/30 16:21 ID:CNVZ7UPn
>>398
最悪でも改行されてればいいんじゃないの？
最悪でも改行されてればいいんじゃないの？
401 ：茶文字 ◆xELvisFU ：02/04/30 16:23 ID:3v5jUQXi
402 ：Name_Not_Found：02/04/30 16:28 ID:nVAh8k61
>>397
何事かと思ったらニセ茶文字かい。
何事かと思ったらニセ茶文字かい。
403 ：Name_Not_Found：02/04/30 16:33 ID:Lkne3TFS
>>394
ｶﾅｰﾘ前にあったけど、要するに「CSSオフを想定して、その上で見栄えを
調整するなら物理要素を使うしかない」し、逆に「物理要素を排除した場合、
見栄えがどうなるかは UA 次第」なんだから strict 指向を叫んで、物理要素を
排除しつつ、見栄えを調整しようというのはｱﾌｫのやる事。
ｶﾅｰﾘ前にあったけど、要するに「CSSオフを想定して、その上で見栄えを
調整するなら物理要素を使うしかない」し、逆に「物理要素を排除した場合、
見栄えがどうなるかは UA 次第」なんだから strict 指向を叫んで、物理要素を
排除しつつ、見栄えを調整しようというのはｱﾌｫのやる事。
404 ：Name_Not_Found：02/04/30 16:36 ID:jmlCFDfm
>>401
騙りｶｺﾜﾙｲ
騙りｶｺﾜﾙｲ
ちょい解りにくい書き込みだったな。
例えば強調個所を<strong>強調</strong>としつつ、
「でもCSS off時も太字にしたいから」といって<strong><b>強調</b></strong>
と書くのはどうか、と提案してるのと何処が違うのか、と言う話。
hr も b も両方とも HTML 4.01 strict で認められているが完璧な物理要素。
区切り線なら hr という発想が強調なら b という物理マークアッパーの発想に等しい。
例えば強調個所を<strong>強調</strong>としつつ、
「でもCSS off時も太字にしたいから」といって<strong><b>強調</b></strong>
と書くのはどうか、と提案してるのと何処が違うのか、と言う話。
hr も b も両方とも HTML 4.01 strict で認められているが完璧な物理要素。
区切り線なら hr という発想が強調なら b という物理マークアッパーの発想に等しい。
407 ：Name_Not_Found：02/04/30 16:46 ID:om3VAEir
>>404
茶文字の偽物、粘着すぎ。
茶文字の偽物、粘着すぎ。
408 ：Name_Not_Found：02/04/30 17:02 ID:PK94sE+n
茶文字 もうだめぽ
409 ：Name_Not_Found：02/04/30 19:02 ID:CNVZ7UPn
>>406
ここは潔癖なスレじゃなかったのですか？
ここは潔癖なスレじゃなかったのですか？
410 ：Name_Not_Found：02/04/30 20:15 ID:BDZxAn0C
>>405
> 「でもCSS off時も太字にしたいから」
なぜ太字にしたいのですか？
・強調したい->XHTMLStrict(strong要素)+CSSを用いる
・特に無意味に太字にしたい->[推奨]SVGを用いる。[互換]XHTMLTransitional(b要素)を用いる
音声ブラウザの今後の普及のために・・・。
> 「でもCSS off時も太字にしたいから」
なぜ太字にしたいのですか？
・強調したい->XHTMLStrict(strong要素)+CSSを用いる
・特に無意味に太字にしたい->[推奨]SVGを用いる。[互換]XHTMLTransitional(b要素)を用いる
音声ブラウザの今後の普及のために・・・。
411 ：Name_Not_Found：02/04/30 20:17 ID:BDZxAn0C
hr要素については45に代替案がある。
412 ：Name_Not_Found：02/04/30 20:29 ID:5oiP8t5i
413 ：Name_Not_Found：02/04/30 21:28 ID:ts26sBA/
茶文字ﾀﾝの恥晒しサイトまだーーー？
414 ：Name_Not_Found：02/05/02 19:44 ID:8Qz7cn1z
another lint gatewayはxhtml1.1はかなり甘いみたい
http://www.ac.wakwak.com/~tgw/
のサイトが１００点になったりマイナス１４点になったりマイナス７２点になったり・・
再現性チェックよろ。
http://www.ac.wakwak.com/~tgw/
のサイトが１００点になったりマイナス１４点になったりマイナス７２点になったり・・
再現性チェックよろ。
415 ：Name_Not_Found：02/05/02 20:22 ID:Hck7EAgq
416 ：Name_Not_Found：02/05/02 21:24 ID:IDVxnNHN
417 ：Name_Not_Found：02/05/02 22:34 ID:Xwb0ANUN
どこで聞いたらいいのかわからんのでここで。スレ違いだったらｽﾏｿ。
<?xml version="1.0" encoding="x-euc-jp"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja">
<head>
<meta http-equiv="content-type" content="text/html;charset=x-euc-jp" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<meta http-equiv="Content-Language" content="ja" />
<meta name="title" content="hogehoge" />
<meta name="author" content="mona" />
<meta name="description" content="w3c信者になりたいのです。" />
<meta name="keywords" content="xhtml,w3c他色々。" />
<link rev="made" href="mailto:～" />
<link rel="stylesheet" type="text/css" href="ahya.css">
どっかおかしいとこありますか？encording=""の指定って大文字じゃないと
いかんですか？
<?xml version="1.0" encoding="x-euc-jp"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja">
<head>
<meta http-equiv="content-type" content="text/html;charset=x-euc-jp" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<meta http-equiv="Content-Language" content="ja" />
<meta name="title" content="hogehoge" />
<meta name="author" content="mona" />
<meta name="description" content="w3c信者になりたいのです。" />
<meta name="keywords" content="xhtml,w3c他色々。" />
<link rev="made" href="mailto:～" />
<link rel="stylesheet" type="text/css" href="ahya.css">
どっかおかしいとこありますか？encording=""の指定って大文字じゃないと
いかんですか？
418 ：Name_Not_Found：02/05/02 22:47 ID:5146MrFy
大文字小文字は関係ない。
というか、W3C 信者が何故 x- …。
encoding="euc-jp" にしましょう。
というか、W3C 信者が何故 x- …。
encoding="euc-jp" にしましょう。
419 ：Name_Not_Found：02/05/02 23:00 ID:fOpjfQ4B
420 ：Name_Not_Found：02/05/02 23:16 ID:fshGH1N4
>>417
link 閉じてない。
link 閉じてない。
421 ：Name_Not_Found：02/05/02 23:20 ID:hZ3TviXS
私はW3C信者で、かつUnicode信者です。
どうでもいいかもしれませんが、
Content-Type は application/xhtml+xml にしてはどうですか?
どうでもいいかもしれませんが、
Content-Type は application/xhtml+xml にしてはどうですか?
423 ：Name_Not_Found：02/05/02 23:33 ID:qtyA/Bro
>>421
某方面見て知ったばかりの知識を嬉しそうにひけらかすのはちょっと恥ずかしいよ。
某方面見て知ったばかりの知識を嬉しそうにひけらかすのはちょっと恥ずかしいよ。
424 ：Name_Not_Found：02/05/02 23:51 ID:fOpjfQ4B
＞某方面
ここで言ってもしょうがないんだが、あまりにがっかりしたので愚痴。
W3C Note の位置付け解ってんのかと小一時間(略。
「踏絵」とか「HTML4まで後退」とか言ってるし。しっかりしろよと思う。
どーせ HTML で使えない XHTML の機能なんか一つも使ってやしないくせに。
それは text/html 以上の何者でもない。ただの XHTML 互換 HTML4。
ここで言ってもしょうがないんだが、あまりにがっかりしたので愚痴。
W3C Note の位置付け解ってんのかと小一時間(略。
「踏絵」とか「HTML4まで後退」とか言ってるし。しっかりしろよと思う。
どーせ HTML で使えない XHTML の機能なんか一つも使ってやしないくせに。
それは text/html 以上の何者でもない。ただの XHTML 互換 HTML4。
425 ：Name_Not_Found：02/05/02 23:56 ID:xM2Sy12G
>>423
というより、何で今あんな話をしているのか良く分らない。
というより、何で今あんな話をしているのか良く分らない。
426 ：Name_Not_Found：02/05/03 00:30 ID:pugFLV+F
カッコつけだけのためにXHTMLを使ってるヤシが多すぎたと思われ。
「今日からXHTMLじゃなくHTML4で書け」
と言われても、困る人はほとんどいないだろう？
「今日からXHTMLじゃなくHTML4で書け」
と言われても、困る人はほとんどいないだろう？
428 ：Name_Not_Found：02/05/03 01:00 ID:r0+CIRWf
>>427
半年前てぇと・・・
半年前てぇと・・・
429 ：うし２歳 ◆Cow.owR. ：02/05/03 08:54 ID:GCareC34
430 ：Name_Not_Found：02/05/03 08:57 ID:vKIcQIEn
ttp://members.jcom.home.ne.jp/pctips/www/test/tree_css.html
で使われているようなCSSプロパティがMSIEで実装されないものか。
そうすればナビゲーションリンクを
<ul class="navigation">
<li>Top Page</li>
<li>Content1</li>
<li>Content2</li>
<li>Content3</li>
<li>Links</li>
</ul>
というふうに記述したときに
Top Page | Content1 | Content2 | Content3 | Links
と表示させたりできると思うんだが。早く実装しないものかねー。
で使われているようなCSSプロパティがMSIEで実装されないものか。
そうすればナビゲーションリンクを
<ul class="navigation">
<li>Top Page</li>
<li>Content1</li>
<li>Content2</li>
<li>Content3</li>
<li>Links</li>
</ul>
というふうに記述したときに
Top Page | Content1 | Content2 | Content3 | Links
と表示させたりできると思うんだが。早く実装しないものかねー。
431 ：うし２歳 ◆Cow.owR. ：02/05/03 08:59 ID:GCareC34
432 ：Name_Not_Found：02/05/03 09:03 ID:HBZaYooh
>>431
関係ないけど、日本Gateway跡地にﾜﾗﾀ。
関係ないけど、日本Gateway跡地にﾜﾗﾀ。
433 ：Name_Not_Found：02/05/03 09:20 ID:vKIcQIEn
ところで
<dl>
<dt>参考URL</dt>
<dd><a href="http://www.xxx.com"></a></dd>
<dd><a href="http://www.yyy.com"></a></dd>
<dd><a href="http://www.zzz.com"></a></dd>
</dl>
と
<dl>
<dt>参考URL</dt>
<dd>
<ul>
<li><a href="http://www.xxx.com"></a></li>
<li><a href="http://www.yyy.com"></a></li>
<li><a href="http://www.zzz.com"></a></li>
</ul>
</dd>
</dl>
ではどっちが適切？
<dl>
<dt>参考URL</dt>
<dd><a href="http://www.xxx.com"></a></dd>
<dd><a href="http://www.yyy.com"></a></dd>
<dd><a href="http://www.zzz.com"></a></dd>
</dl>
と
<dl>
<dt>参考URL</dt>
<dd>
<ul>
<li><a href="http://www.xxx.com"></a></li>
<li><a href="http://www.yyy.com"></a></li>
<li><a href="http://www.zzz.com"></a></li>
</ul>
</dd>
</dl>
ではどっちが適切？
434 ：うし２歳 ◆Cow.owR. ：02/05/03 09:36 ID:GCareC34
>>432 正解、そこ笑うところ。
とりあえず<meta http-equiv="Content-Type"… で application/xhtml+xml 指定してみたがどうなのだろうか。
>>433
<h*>参考URL</h*>
<ul>
<li><a href="http://www.xxx.com"></a></li>
<li><a href="http://www.yyy.com"></a></li>
<li><a href="http://www.zzz.com"></a></li>
</ul>
かもよ？
等といってさらに混乱させてみる。
とりあえず<meta http-equiv="Content-Type"… で application/xhtml+xml 指定してみたがどうなのだろうか。
>>433
<h*>参考URL</h*>
<ul>
<li><a href="http://www.xxx.com"></a></li>
<li><a href="http://www.yyy.com"></a></li>
<li><a href="http://www.zzz.com"></a></li>
</ul>
かもよ？
等といってさらに混乱させてみる。
435 ：Name_Not_Found：02/05/03 09:45 ID:wIWsakxr
436 ：Name_Not_Found：02/05/03 13:11 ID:jwrHObKC
437 ：Name_Not_Found：02/05/03 14:29 ID:fLD6lW9y
>>430
そのくらいなら CSS2 でもできるよ。
.navigation li {
display:inline;
border-left:solid thin;
}
.navigation li:first-child {
border-left:none;
}
>>431
IE は meta http-equiv="content-type" のシカトで有名かと思われ(charset は読んでるけど)。
text/html とか image/png にしても読めるはず。
生の HTTP ヘッダで application/xhtml+xml 吐いても解釈できるのは
Mozilla と Opera6 くらい。
そのくらいなら CSS2 でもできるよ。
.navigation li {
display:inline;
border-left:solid thin;
}
.navigation li:first-child {
border-left:none;
}
>>431
IE は meta http-equiv="content-type" のシカトで有名かと思われ(charset は読んでるけど)。
text/html とか image/png にしても読めるはず。
生の HTTP ヘッダで application/xhtml+xml 吐いても解釈できるのは
Mozilla と Opera6 くらい。
438 ：Name_Not_Found：02/05/03 14:42 ID:TPWRTRbg
application/xhtml+xmlはXHTML 2.0のためのものでは? XHTML 1.xはtext/htmlだろ?
439 ：うし２歳 ◆Cow.owR. ：02/05/03 15:16 ID:GCareC34
>>438
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020430/
の真ん中をすぎたあたりの表参照。
>>364 の
｜ところでhttp://www.w3.org/TR/html4/からLatest version of HTMLのURIへ行くと
｜XHTML 1.0の仕様書になるね。なぜXHTML 1.1でないのだろう。
と何か関係が…？
（笑
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020430/
の真ん中をすぎたあたりの表参照。
>>364 の
｜ところでhttp://www.w3.org/TR/html4/からLatest version of HTMLのURIへ行くと
｜XHTML 1.0の仕様書になるね。なぜXHTML 1.1でないのだろう。
と何か関係が…？
（笑
440 ：Name_Not_Found：02/05/03 15:21 ID:TPWRTRbg
>>439情報サンクスです。石川雅康さん、マジっすか！ この際ウェブページの拡張子xmlにして広告抑えるか。
441 ：Name_Not_Found：02/05/03 15:29 ID:Qkgx5MuK
>>438
application/xhtml+xml は XHTML Family 全般のためのもの。
XHTML のための MediaType 新設は XHTML1.0 草案当時に既に検討されているよ。
http://www.doraneko.org/xml/xhtml10/WD990304.html#media
application/xhtml+xml は XHTML Family 全般のためのもの。
XHTML のための MediaType 新設は XHTML1.0 草案当時に既に検討されているよ。
http://www.doraneko.org/xml/xhtml10/WD990304.html#media
>>440
マジです。
マジです。
呼んだ？
444 ：Name_Not_Found：02/05/03 17:01 ID:te79HcDu
>>434
application/xhtml+xmlなXHTMLなら<meta http-equiv="Content-Type" .../>
はいらないのでは。
あれはhttpヘッダのcharset指定の一時的な代替として採用されたにすぎない。
httpヘッダでapplication/xhtml+xml; charset=...
とすべき。
application/xhtml+xmlなXHTMLなら<meta http-equiv="Content-Type" .../>
はいらないのでは。
あれはhttpヘッダのcharset指定の一時的な代替として採用されたにすぎない。
httpヘッダでapplication/xhtml+xml; charset=...
とすべき。
445 ：Name_Not_Found：02/05/03 17:09 ID:/iIFySvM
>>444
サーバによっては読み込んで処理してくれるから、でしょ。
サーバによっては読み込んで処理してくれるから、でしょ。
446 ：Name_Not_Found：02/05/03 18:15 ID:RtPZhskX
>>445
サーバーがmetaをいちいち読むのは非現実的ということで
できるなら自分で指定すべきとなったはず。
metaのない.txtや.xml等々も考えればhttpヘッダで指定するべき。
（xml宣言のencodingは伝送時には使われない）
サーバーがmetaをいちいち読むのは非現実的ということで
できるなら自分で指定すべきとなったはず。
metaのない.txtや.xml等々も考えればhttpヘッダで指定するべき。
（xml宣言のencodingは伝送時には使われない）
W3Cのxhtml-roadmapのXHTML 2.0の項に昔そんなこと書いていなかったっけ? 勘違いしていたよ。
>>441
XHTML 1.0/1.1の勧告には間に合わなかったみたいで記載されていないようですね。
>>446
> サーバーがmetaをいちいち読むのは非現実的ということで
Namazuみたいに定期的に巡回すればそう非現実的ではないはず。
>（xml宣言のencodingは伝送時には使われない）
冗長となるが、使われないわけではないのでは? XHTML 仕様書にはプロトコルのcontent-typeとxml宣言のencoding指定は一致しなければならないという記述があるが。
>>441
XHTML 1.0/1.1の勧告には間に合わなかったみたいで記載されていないようですね。
>>446
> サーバーがmetaをいちいち読むのは非現実的ということで
Namazuみたいに定期的に巡回すればそう非現実的ではないはず。
>（xml宣言のencodingは伝送時には使われない）
冗長となるが、使われないわけではないのでは? XHTML 仕様書にはプロトコルのcontent-typeとxml宣言のencoding指定は一致しなければならないという記述があるが。
448 ：Name_Lots_Found：02/05/04 00:07 ID:N7ZwvIqi
>>466-467
XML宣言のencodingとかが(UTF系以外では)なぜ必須かと言えば、
HTTP以外の経路で読まなきゃならないことを想定しているのではないかと。
つまり、HTTPで送るならHTTPヘッダでencodingを送るべきだけど、
社内データベースとかでローカルに処理するときはencodingを
直接文書から読まないとにっちもさっちもいかない場合があるって事で。
XML宣言のencodingとかが(UTF系以外では)なぜ必須かと言えば、
HTTP以外の経路で読まなきゃならないことを想定しているのではないかと。
つまり、HTTPで送るならHTTPヘッダでencodingを送るべきだけど、
社内データベースとかでローカルに処理するときはencodingを
直接文書から読まないとにっちもさっちもいかない場合があるって事で。
449 ：Name_Lots_Found：02/05/04 00:10 ID:N7ZwvIqi
はふー、 >>446-447 だった
450 ：Name_Not_Found：02/05/04 11:00 ID:jwScFitv
>>447
サーバがmetaを読んでヘッダを形成するというのは、
最初はその予定だったらしいが、そんなサーバは普及しなかった
のと、text/plainなんかはどうしようも無いということで、
サーバがmetaを読むという話はとうの昔に却下された。
そんなわけで、「非現実的ではないはず」と言われても、もう遅い。
今ではmetaはhttpヘッダでcharsetを付けない、付けられない人のために
認められてるだけ。しかもW3Cは仕方なく認めてるが、IETFは認めてないそうです。
サーバがmetaを読んでヘッダを形成するというのは、
最初はその予定だったらしいが、そんなサーバは普及しなかった
のと、text/plainなんかはどうしようも無いということで、
サーバがmetaを読むという話はとうの昔に却下された。
そんなわけで、「非現実的ではないはず」と言われても、もう遅い。
今ではmetaはhttpヘッダでcharsetを付けない、付けられない人のために
認められてるだけ。しかもW3Cは仕方なく認めてるが、IETFは認めてないそうです。
451 ：茶文字 ◆xELvisFU ：02/05/04 11:09 ID:Lj8GCVDH
Web鯖を立ててないLAN環境などの場合は、ハイパーリンクするなら
a要素にtype属性を加えておくという工夫はできるね。
UAが対応してるのか甚だ疑問だし、どこかからのリンクではなくて
いきなりそのファイルにアクセスしたときはやっぱり困るけど。
a要素にtype属性を加えておくという工夫はできるね。
UAが対応してるのか甚だ疑問だし、どこかからのリンクではなくて
いきなりそのファイルにアクセスしたときはやっぱり困るけど。
452 ：Name_Not_Found：02/05/04 11:10 ID:uIi4k2gs
453 ：Name_Not_Found：02/05/04 21:50 ID:D93223xR
発売日 2003年発売予定
対応機種 Windows®98/Me/NT4.0/2000/XP
価格 3,800円（税別）
ジャンル ＲＰＧ
供給媒体 DVD-ROM １枚
周辺機器 8ボタンジョイパッド
の場合、 dl でマークアップしなければ間違いだと思うけど、上記のように横一列に表示させるにはどんな方法があります？
li ならinlineで可能ですけどマークアップ的には不適切でそれならtableの方が適切ですし…
対応機種 Windows®98/Me/NT4.0/2000/XP
価格 3,800円（税別）
ジャンル ＲＰＧ
供給媒体 DVD-ROM １枚
周辺機器 8ボタンジョイパッド
の場合、 dl でマークアップしなければ間違いだと思うけど、上記のように横一列に表示させるにはどんな方法があります？
li ならinlineで可能ですけどマークアップ的には不適切でそれならtableの方が適切ですし…
454 ：453：02/05/04 22:01 ID:D93223xR
<h2>仕様</h2>
<dl>
<dt>発売日</dt>
<dd>2003年発売予定</dd>
<dt>対応機種</dt>
<dd>Windows®98/Me/NT4.0/2000/XP</dd>
<dt>価格</dt>
<dd>3,800円（税別）</dd>
<dt>ジャンル</dt>
<dd>ＲＰＧ</dd>
<dt>周辺機器</dt>
<dd>ジョイパッド必須</dd>
</dl>
こんな感じです。
<dl>
<dt>発売日</dt>
<dd>2003年発売予定</dd>
<dt>対応機種</dt>
<dd>Windows®98/Me/NT4.0/2000/XP</dd>
<dt>価格</dt>
<dd>3,800円（税別）</dd>
<dt>ジャンル</dt>
<dd>ＲＰＧ</dd>
<dt>周辺機器</dt>
<dd>ジョイパッド必須</dd>
</dl>
こんな感じです。
455 ：Name_Not_Found：02/05/04 22:01 ID:NdsUv0g0
FAQです。スタイルシートを使います。
http://pc.2ch.net/test/read.cgi/hp/1015474859/586
http://pc.2ch.net/test/read.cgi/hp/1015474859/586
456 ：Name_Not_Found：02/05/04 22:02 ID:qazISkI8
display:run-in;って書いてみてあとはUAのサポートを指をくわえて待つ
457 ：Name_Not_Found：02/05/04 22:04 ID:hP9qDRi8
>>455
サンクス。なんかfloatまで頭回ってなかったみたい
サンクス。なんかfloatまで頭回ってなかったみたい
459 ：Name_Not_Found：02/05/04 22:13 ID:NdsUv0g0
>>456
指がふやけて、溶けて、ぼろぼろになりそうに思われますです。。。
指がふやけて、溶けて、ぼろぼろになりそうに思われますです。。。
460 ：Name_Not_Found：02/05/04 22:20 ID:J6CAixaX
いっそテーブル。
461 ：Name_Not_Found：02/05/04 22:22 ID:NdsUv0g0
>>460
tableよりはdlのほうがいいよ。アクセシビリティが高い(xhtml host modulesに含まれている)。
tableよりはdlのほうがいいよ。アクセシビリティが高い(xhtml host modulesに含まれている)。
>>460
いや、445のでできたからいいや。N4なんてどうでもいいし
いや、445のでできたからいいや。N4なんてどうでもいいし
>>434-435
hmm...
>>437
そうかあ、仕切り腺程度ならボーダーでできるね。全然気がつかなかった。
しかし
Top Page > xxx index > xxx Page
というような場合は……画像を指定でなんとかなるだろうか
hmm...
>>437
そうかあ、仕切り腺程度ならボーダーでできるね。全然気がつかなかった。
しかし
Top Page > xxx index > xxx Page
というような場合は……画像を指定でなんとかなるだろうか
464 ：Name_Not_Found：02/05/05 17:53 ID:tsr9JA2G
465 ：Name_Not_Found：02/05/05 19:45 ID:mxUJymAv
>>464
IE が対応してないから別の方法を考えてるんじゃないかな？
IE が対応してないから別の方法を考えてるんじゃないかな？
466 ：Name_Not_Found：02/05/05 21:04 ID:CfS4S+td
つまり>>430は、今現在のUAでなおかつ極力strictで、と
言いたいんだよな（既出）。
>>437で十分だと思うけども、画像にしたくて>>464を使いたくないなら、
paddingを余計にとってbackground-imageとbackground-position:right center
でどうよ？汚いけど。
擦れ違いｽﾏｿ
言いたいんだよな（既出）。
>>437で十分だと思うけども、画像にしたくて>>464を使いたくないなら、
paddingを余計にとってbackground-imageとbackground-position:right center
でどうよ？汚いけど。
擦れ違いｽﾏｿ
467 ：Name_Not_Found：02/05/05 22:36 ID:tsr9JA2G
今現在のUAでという発想がそもそも非strict的では
468 ：Name_Not_Found：02/05/05 22:57 ID:CfS4S+td
>>467
けどそれを言ったらこのｽﾚは未来日記かobsolete。
けどそれを言ったらこのｽﾚは未来日記かobsolete。
469 ：Name_Not_Found：02/05/05 23:01 ID:kOKDA/yO
>>463
パンくずリストは、そのままでも良いかと思った。
パンくずリストは、そのままでも良いかと思った。
470 ：Name_Not_Found：02/05/06 00:26 ID:1TCw0G80
*CSS なんて飾り*です。素直に content を使おう。
471 ：Name_Not_Found：02/05/06 03:11 ID:80Qr5G0z
.htaccessで
AddType "text/html; charset=shift_jis" html
とした場合
ソースに
<meta http-equiv="conten-type" content="text/html; charset=shift_jis">
って
冗長ですかね？
AddType "text/html; charset=shift_jis" html
とした場合
ソースに
<meta http-equiv="conten-type" content="text/html; charset=shift_jis">
って
冗長ですかね？
472 ：Name_Not_Found：02/05/06 03:35 ID:D1nsUBlW
473 ：Name_Not_Found：02/05/06 17:52 ID:DT2GISPQ
>>472
XHTML 1.1はContent-typeが、
application/xmlまたはapplication/xhtml+xmlのとき: NEED NOT
text/htmlのとき: SHOULD
だと思う。
XHTML 1.1はContent-typeが、
application/xmlまたはapplication/xhtml+xmlのとき: NEED NOT
text/htmlのとき: SHOULD
だと思う。
474 ：Name_Not_Found：02/05/06 22:30 ID:7MK/iviX
スレ違いかもしれないんですが、HTMLやXHTMLのMIMEタイプの
変更ってどうやるんですか？ 単に head 内に
<meta http-equiv="content-type" content="application/xhtml+xml; charset=shift_jis" />
では駄目ですか？
変更ってどうやるんですか？ 単に head 内に
<meta http-equiv="content-type" content="application/xhtml+xml; charset=shift_jis" />
では駄目ですか？
475 ：Name_Not_Found：02/05/06 22:42 ID:DT2GISPQ
>>475
えと、http://の場合です。
具体的にはXHTMLでweb siteを公開していて、各地でapplication/xhtml+xmlが
云々と言う話になっているのでとりあえず自分も実験的にmetaで>>474の通りに
設定してみたのでですが、各地で騒がれているデメリットが全く発生しないので、
自分のやっている設定ではどうやら違うか、不足らしい、と言う事での質問です。
因みにISPはCGIを一部条件付で許しているので.htaccessは設置できると思います。
（CGIは全く解っていないので、.htaccessがなんなのか解っていないのですが）
えと、http://の場合です。
具体的にはXHTMLでweb siteを公開していて、各地でapplication/xhtml+xmlが
云々と言う話になっているのでとりあえず自分も実験的にmetaで>>474の通りに
設定してみたのでですが、各地で騒がれているデメリットが全く発生しないので、
自分のやっている設定ではどうやら違うか、不足らしい、と言う事での質問です。
因みにISPはCGIを一部条件付で許しているので.htaccessは設置できると思います。
（CGIは全く解っていないので、.htaccessがなんなのか解っていないのですが）
477 ：Name_Not_Found：02/05/06 23:52 ID:j6iYuc+7
>>476
.xhtml を全部 application/xhtml+xml にするなら、
.htaccess ていう名前をつけたテキストファイルに
AddType "application/xhtml+xml; charset=shift_jis" html (改行)
って書いてうｐする。あとこまいことは
ttp://www.mikeneko.ne.jp/~lab/web/htaccess/
あたりを見ればわかると思う。
.xhtml を全部 application/xhtml+xml にするなら、
.htaccess ていう名前をつけたテキストファイルに
AddType "application/xhtml+xml; charset=shift_jis" html (改行)
って書いてうｐする。あとこまいことは
ttp://www.mikeneko.ne.jp/~lab/web/htaccess/
あたりを見ればわかると思う。
479 ：Name_Not_Found：02/05/07 01:59 ID:FTk6HQea
ちなみに、application/xhtml+xmlを吐かせると得られるメリットって
（将来的なものも含め）どんなことがあるんですか？
（将来的なものも含め）どんなことがあるんですか？
480 ：Name_Not_Found：02/05/07 02:34 ID:kOZo6jPa
481 ：Name_Not_Found：02/05/07 09:27 ID:TyWgiUbz
現在的なデメリットが多いので、text/html を使うべさ。
XHTML はテキストファイルだべ。
XHTML はテキストファイルだべ。
482 ：Name_Not_Found：02/05/07 11:15 ID:dOwLw28L
text/htmlとapplication/xhtml+xmlとapplication/xmlでコンテントネゴシエーションを使うのが最良の方法かと。
483 ：Name_Not_Found：02/05/07 11:30 ID:G035VWBn
テキストファイルだからtext/*になるんじゃないよ。
text/htmlならhtmlの知識の無い人がソースを見て理解できる内容でなくては。
その意味でIETFなんかはapplication/htmlにすべきだったと後悔してるが、もう遅い。
xmlもそのほとんどはtext/xmlではなくてapplication/xmlに該当する。
text/htmlならhtmlの知識の無い人がソースを見て理解できる内容でなくては。
その意味でIETFなんかはapplication/htmlにすべきだったと後悔してるが、もう遅い。
xmlもそのほとんどはtext/xmlではなくてapplication/xmlに該当する。
484 ：Name_Not_Found：02/05/07 15:14 ID:M8tLril/
下がり過ぎてるのでage。
485 ：Name_Not_Found：02/05/07 20:02 ID:Phltqxqf
なんだか、高度（？）な話題の中、こんな質問するのもなんですが
ナビゲーションってどういう風にマークアップするのが理想的なんですか？
例えば
<div id="navigation">
<ul>
<li><a href="./about.html">about</a></li>
<li><a href="./text.html">text</a></li>
</ul>
</div>
っていうリスト付けて、あとはCSSで見栄え表現。
もしくは
<div id="navigation">
<a href="./about.html">about</a> / <a href="./text.html">text</a>
</div>
っていう風にするのと、どっちが良いんでしょう？
たぶん、最初のほうなんでしょうけど…。なんかこの頃、使いやすいナビゲーションリンクってのが
よく解らなくなって来ていて(;´Д`)
ナビゲーションってどういう風にマークアップするのが理想的なんですか？
例えば
<div id="navigation">
<ul>
<li><a href="./about.html">about</a></li>
<li><a href="./text.html">text</a></li>
</ul>
</div>
っていうリスト付けて、あとはCSSで見栄え表現。
もしくは
<div id="navigation">
<a href="./about.html">about</a> / <a href="./text.html">text</a>
</div>
っていう風にするのと、どっちが良いんでしょう？
たぶん、最初のほうなんでしょうけど…。なんかこの頃、使いやすいナビゲーションリンクってのが
よく解らなくなって来ていて(;´Д`)
486 ：Name_Not_Found：02/05/07 20:10 ID:6/92vdiX
>>485
個人的にはulを使ったリスト形式の方が好みだが、divを使わず、ulにidを
書き込んだ方が良いのでは?
ナビゲーションリストの話は定期的に繰り返されているので、過去スレ / レス を
読んだ上でお好みで。
ただ、strictスレ的には後者の区切り線を"/"とテキストで書いてしまうのは
ちょっといただけないかも。
CSSのborderかoutlineかcontentプロパティを使う事を検討してみてください。
個人的にはulを使ったリスト形式の方が好みだが、divを使わず、ulにidを
書き込んだ方が良いのでは?
ナビゲーションリストの話は定期的に繰り返されているので、過去スレ / レス を
読んだ上でお好みで。
ただ、strictスレ的には後者の区切り線を"/"とテキストで書いてしまうのは
ちょっといただけないかも。
CSSのborderかoutlineかcontentプロパティを使う事を検討してみてください。
487 ：Name_Not_Found：02/05/07 21:20 ID:Ys8e+Gpm
Content-Typeでコンテントネゴシエーションってどうやるのですか？
ttp://www.mikeneko.ne.jp/~lab/web/htaccess/
を見てみたんですが、言語ネゴシエーションしか書いてなかったです。
ttp://www.mikeneko.ne.jp/~lab/web/htaccess/
を見てみたんですが、言語ネゴシエーションしか書いてなかったです。
488 ：Name_Not_Found：02/05/07 21:59 ID:jLknqMuQ
過激Strictではナビゲーションは全部link要素に書く。
489 ：Name_Not_Found：02/05/07 22:02 ID:y/NLk50R
なるほど、だいたい理解できました。
ついでにもう一つ、質問です。
<a href="#top" accesskey="b">上に戻る (b)</a>
っていう一番上まで戻るリンクってよくありますよね。これって必要でしょうか？
個人的には必要じゃないと思うんですけど…Strictなサイトって殆どが、これを用意しているので…。
ついでにもう一つ、質問です。
<a href="#top" accesskey="b">上に戻る (b)</a>
っていう一番上まで戻るリンクってよくありますよね。これって必要でしょうか？
個人的には必要じゃないと思うんですけど…Strictなサイトって殆どが、これを用意しているので…。
491 ：Name_Not_Found：02/05/07 22:23 ID:iOtQlIuV
>>490
自分の作ったページを、安ノートPC並の 640*480の解像度で見たらどうだろうか？
自分の作ったページを、安ノートPC並の 640*480の解像度で見たらどうだろうか？
492 ：Name_Not_Found：02/05/07 22:35 ID:hwReGYXX
>>488
過激じゃないstrict派も基本的にlinkに書きますね。
linkにかいてあるからbody内にナビゲーションは要らない、と言う奴は
過激派ですが (漏れはMozilla派なので、linkのみでも別に困らないが)。
>>490
>Strictなサイトって殆どが、これを用意しているので
俺の知っているstrictなHTMLで書かれたサイトは殆ど「上に戻る」ボタンを
もっていない。たまたまでは？
ナビゲーションは「contentsの閲覧を助ける」為の「contents」であり、
あくまでcontentsなので、strictか否かは関係ないです。個人的にいらないと思えば要らない筈。
過激じゃないstrict派も基本的にlinkに書きますね。
linkにかいてあるからbody内にナビゲーションは要らない、と言う奴は
過激派ですが (漏れはMozilla派なので、linkのみでも別に困らないが)。
>>490
>Strictなサイトって殆どが、これを用意しているので
俺の知っているstrictなHTMLで書かれたサイトは殆ど「上に戻る」ボタンを
もっていない。たまたまでは？
ナビゲーションは「contentsの閲覧を助ける」為の「contents」であり、
あくまでcontentsなので、strictか否かは関係ないです。個人的にいらないと思えば要らない筈。
493 ：Name_Not_Found：02/05/07 22:37 ID:ijhAU1tE
自分のサイトは長い文章とかが、殆どないので、付けない事にします。
有り難うございました～。
有り難うございました～。
495 ：茶文字 ◆xELvisFU ：02/05/07 22:47 ID:u4gDs/e0
>>490
Strictとユーザビリティーは関係の深いことがらではあるけれど、
Strictなマークアップをすればユーザビリティーが向上するかというと
必ずしもそうとは限らない。
また、Strictじゃないマークアップでもユーザビリティーを向上することは
ある程度可能でもある。
だから、「Strictだから必要/不要」という話ではないと思うわけです。
>>493
うちのMacにはHomeに相当するキーがありません(PowerBook2400)。
外付けの拡張キーボードを3つ確認してみたけど、
ついてるのはDOS/V向けを流用した多機能型のやつだけだったな。
accesskey属性はこういうときにありがたいかも。
OSやUAによって若干操作が異なるものの、ある程度UIが統一されるから。
Strictとユーザビリティーは関係の深いことがらではあるけれど、
Strictなマークアップをすればユーザビリティーが向上するかというと
必ずしもそうとは限らない。
また、Strictじゃないマークアップでもユーザビリティーを向上することは
ある程度可能でもある。
だから、「Strictだから必要/不要」という話ではないと思うわけです。
>>493
うちのMacにはHomeに相当するキーがありません(PowerBook2400)。
外付けの拡張キーボードを3つ確認してみたけど、
ついてるのはDOS/V向けを流用した多機能型のやつだけだったな。
accesskey属性はこういうときにありがたいかも。
OSやUAによって若干操作が異なるものの、ある程度UIが統一されるから。
496 ：Name_Not_Found：02/05/07 23:57 ID:jLknqMuQ
IEなんかだったらCommand+↑でもいけるけど、
iCabやOmni、Mozillaはそう言う面で駄目だったりする。
Apple的にはfn+←（=home）推奨みたいだけど。
残念な事に古いハードは見捨ててますな、彼の会社は……
iCabやOmni、Mozillaはそう言う面で駄目だったりする。
Apple的にはfn+←（=home）推奨みたいだけど。
残念な事に古いハードは見捨ててますな、彼の会社は……
497 ：Name_Not_Found：02/05/08 01:07 ID:Gw/1JzoJ
Moz は ContextMenu-Extensions かなぁ。
ページトップに移動するリンク(みたいの)が簡単につけられる。
外部拡張になるけど、あれは便利。
ページトップに移動するリンク(みたいの)が簡単につけられる。
外部拡張になるけど、あれは便利。
498 ：Name_Not_Found：02/05/08 01:41 ID:9GVBnNkI
strictなHTMLの記述とユーザビリティですが、ウチのPCに該当キィがあるか、
無いか、ではなく、Web Siteの製作者側がHTMLのコンテンツとして書き込むべき
内容なのか、それともUAやユーザ側が用意すべきものなのか、と言う点が重要だと
思われ。
極論言えば、キィが無いからHTMLに書いてくれ、と言う理論は、戻るボタンない
UAが有るかもしれないから、全てのHTMLはjava scriptで戻るボタンを用意すべし
って話になりかねないな、と思う (飽くまで極論としてだが)。
無いか、ではなく、Web Siteの製作者側がHTMLのコンテンツとして書き込むべき
内容なのか、それともUAやユーザ側が用意すべきものなのか、と言う点が重要だと
思われ。
極論言えば、キィが無いからHTMLに書いてくれ、と言う理論は、戻るボタンない
UAが有るかもしれないから、全てのHTMLはjava scriptで戻るボタンを用意すべし
って話になりかねないな、と思う (飽くまで極論としてだが)。
499 ：Name_Not_Found：02/05/08 02:22 ID:ftPI6yw7
これ以上はユーザビリティーｽﾚへGo.
500 ：Name_Not_Found：02/05/08 05:58 ID:zmNnfpaG
>>487
AddType "text/html; charset=utf-8" html
AddType "application/xhtml+xml; charset=utf-8" xhtml
DirectoryIndex index
Options +MultiViews
…かな? (あんま自信ない)
つーか検索すれば見付かるよ。神崎たんのとことか。
AddType "text/html; charset=utf-8" html
AddType "application/xhtml+xml; charset=utf-8" xhtml
DirectoryIndex index
Options +MultiViews
…かな? (あんま自信ない)
つーか検索すれば見付かるよ。神崎たんのとことか。
501 ：Name_Not_Found：02/05/08 12:46 ID:ERYFUhOV
たとえば更新履歴などを書く場合、
<dl>
<dd>××のページを更新。</dd>
<dt>2002-05-08</dt>
<dd>○○のページを移動。</dd>
<dt>2002-05-07</dt>
<dd>□□のページを閉鎖。</dd>
<dt>2002-05-06/dt>
</dl>
という風に、dd要素の後にdt要素（この場合は日付）をもってくるのは、
strict的に問題ないでしょうか？
<dl>
<dd>××のページを更新。</dd>
<dt>2002-05-08</dt>
<dd>○○のページを移動。</dd>
<dt>2002-05-07</dt>
<dd>□□のページを閉鎖。</dd>
<dt>2002-05-06/dt>
</dl>
という風に、dd要素の後にdt要素（この場合は日付）をもってくるのは、
strict的に問題ないでしょうか？
502 ：Name_Not_Found：02/05/08 15:00 ID:Gw/1JzoJ
>>501
普通に dt dd の順で書いてスタイルで動かす方がいいとも思うけど……
普通に dt dd の順で書いてスタイルで動かす方がいいとも思うけど……
>>502
いや、自分も、特別な理由がない限り、dt、ddの順に書いた方がいいとは
思うんですが、そもそもこの順番は、「慣習としてそうなっている」
「ブラウザのデフォルトスタイルで見たときにわかりやすい」という以上
の理由があるのかふと疑問に思ったもので。
あと、「スタイルで動かす」とのことですが、CSSでddとdtの表示順を逆転
させる方法が思いつかないのですが、どうやるんでしょうか。
いや、自分も、特別な理由がない限り、dt、ddの順に書いた方がいいとは
思うんですが、そもそもこの順番は、「慣習としてそうなっている」
「ブラウザのデフォルトスタイルで見たときにわかりやすい」という以上
の理由があるのかふと疑問に思ったもので。
あと、「スタイルで動かす」とのことですが、CSSでddとdtの表示順を逆転
させる方法が思いつかないのですが、どうやるんでしょうか。
504 ：Name_Not_Found：02/05/08 16:05 ID:oZFW/NvY
>>503
過激Strict的にはXSLT。CSSにそのパワーは無い。
過激Strict的にはXSLT。CSSにそのパワーは無い。
505 ：Name_Not_Found：02/05/08 16:41 ID:nNZ/76yL
dt { position: relative; bottom: 1em; }
dd { position: relative; top: 1em; }
でどうだろう。試してないのでちと自信ナシ。
dd { position: relative; top: 1em; }
でどうだろう。試してないのでちと自信ナシ。
506 ：Name_Not_Found：02/05/08 17:22 ID:+Mxib5X0
507 ：Name_Not_Found：02/05/08 17:43 ID:pxU4WqjX
508 ：サ骨 ◆/IQ5000w ：02/05/08 18:05 ID:cf0L6ZZB
509 ：Name_Not_Found：02/05/08 18:30 ID:lAAJPVMP
www.kanzaki.com/のトップが
XMLのデータとして
見えるんすけど
俺だけ？
ネスケだとちゃんと見えるんだけど・・
XMLのデータとして
見えるんすけど
俺だけ？
ネスケだとちゃんと見えるんだけど・・
510 ：サ骨 ◆/IQ5000w ：02/05/08 18:31 ID:cf0L6ZZB
ごめん、自分で意味がわからないていうか勘違いなので>>508修正。
"「××のページを更新」の説明として、「2002-05-08」がある"
と考えてdtとddの中身、順番を入れ替える。502と同意見です。
あと>>502のいう「スタイルで動かす」てのは
上のように書き換えたあと、左マージンを指定する、
ということと思われ。
まぁdtが「定義する用語」、ddが「説明」なので
dtが先に来ることが多いってだけのような気もしますが。
"「××のページを更新」の説明として、「2002-05-08」がある"
と考えてdtとddの中身、順番を入れ替える。502と同意見です。
あと>>502のいう「スタイルで動かす」てのは
上のように書き換えたあと、左マージンを指定する、
ということと思われ。
まぁdtが「定義する用語」、ddが「説明」なので
dtが先に来ることが多いってだけのような気もしますが。
511 ：Name_Not_Found：02/05/08 18:45 ID:KrjZzZT1
512 ：Name_Not_Found：02/05/08 21:15 ID:lAAJPVMP
<link rel="Appendix" href="cgi-bin/bbs.cgi">
ってＳＴＲＩＣＴ的にOKかな？掲示板を付属文章としてみるの
どうよ？
ってＳＴＲＩＣＴ的にOKかな？掲示板を付属文章としてみるの
どうよ？
513 ：茶文字 ◆xELvisFU ：02/05/08 21:36 ID:MmOr4loh
514 ：Name_Not_Found：02/05/08 21:37 ID:lAAJPVMP
<link rel="Appendix" href="links.html">
ってのは使っています。
ってのは使っています。
515 ：Name_Not_Found：02/05/08 22:46 ID:vrv4xlEl
* * *
* *
* Λ＿Λ *
* （ ´ⅴ｀ ） *
* 終了 *
* *
* * *
* *
* Λ＿Λ *
* （ ´ⅴ｀ ） *
* 終了 *
* *
* * *
516 ：Name_Not_Found：02/05/08 23:18 ID:qJK3nC1m
* * *
* *
* Λ＿Λ *
* （ ´ⅴ｀ ） *
* 再開 *
* *
* * *
517 ：Name_Not_Found：02/05/09 01:30 ID:wKp2wKAA
dtとddの関連性は要素の並び順でしか示されないので、
もしdtとddの関連性を推測して何らかの機能を提供するUAがあったとしたら
dd, dt, dd, dt...という順番だとデータが意図通り扱われない可能性が高いでしょうね。
もしdtとddの関連性を推測して何らかの機能を提供するUAがあったとしたら
dd, dt, dd, dt...という順番だとデータが意図通り扱われない可能性が高いでしょうね。
518 ：サ骨 ◆/IQ5000w ：02/05/09 02:44 ID:s+OSXbQK
<dl>
<dt>吉田</dt>
<dt>吉本</dt>
<dt>吉村</dt>
<dt>吉原</dt>
</dl>
てのは無しですか。
<dt>吉田</dt>
<dt>吉本</dt>
<dt>吉村</dt>
<dt>吉原</dt>
</dl>
てのは無しですか。
519 ：Name_Not_Found：02/05/09 03:03 ID:H3qeXEv0
<ul>
<li>吉田</li>
<li>吉本</li>
<li>吉村</li>
<li>吉原</li>
</ul>
<li>吉田</li>
<li>吉本</li>
<li>吉村</li>
<li>吉原</li>
</ul>
520 ：Name_Not_Found：02/05/09 03:24 ID:Tm2tAE4F
>509
もしかして Mac IE 4.5?
もしかして Mac IE 4.5?
521 ：茶文字 ◆xELvisFU ：02/05/09 03:33 ID:2O/a2fbq
>>520
MacIE5も同じ症状があった気がする。
このスレじゃなかったっけ、XHTML関連の質問に「5.1が出たばかりだから
それを入れるといいよ」な回答を見たので即ﾀﾞｳｿした記憶があるから。
>>518
どういう意図(あるいは状況)でそういうマークアップになるの？
MacIE5も同じ症状があった気がする。
このスレじゃなかったっけ、XHTML関連の質問に「5.1が出たばかりだから
それを入れるといいよ」な回答を見たので即ﾀﾞｳｿした記憶があるから。
>>518
どういう意図(あるいは状況)でそういうマークアップになるの？
522 ：Name_Not_Found：02/05/09 07:55 ID:14k+xJAU
>>512
漏れは質問/突っ込み用にしてるから help にしてるけど、
そもそも rel/rev は無理に書かなきゃならないものじゃないよ。
敢えて書くなら appendix か bookmark だろうけど、
どちらかと言えばむしろ title を書くことの方が重要。
<link title="掲示板" href="./board.cgi"/>
漏れは質問/突っ込み用にしてるから help にしてるけど、
そもそも rel/rev は無理に書かなきゃならないものじゃないよ。
敢えて書くなら appendix か bookmark だろうけど、
どちらかと言えばむしろ title を書くことの方が重要。
<link title="掲示板" href="./board.cgi"/>
523 ：Name_Not_Found：02/05/09 09:59 ID:1n6wOapm
>>479
メリットではないかもしれないけど、 DOM 的にも差がある。
(1) <table><tr><td>表</td></tr></table>
(2) <TABLE><TR><TD>表</TD></TR></TABLE>
(3) <table><tbody><tr><td>表</td></tr></tbody></table>
(4) <TABLE><TBODY><TR><TD>表</TD></TR></TBODY></TABLE>
text/html は(1)の構造の(2)(3)(4)のような構造への修正をパーザに認めるようなもの。
application/xhtml+xml であればそれぞれ違う構造だと明示できる。
メリットではないかもしれないけど、 DOM 的にも差がある。
(1) <table><tr><td>表</td></tr></table>
(2) <TABLE><TR><TD>表</TD></TR></TABLE>
(3) <table><tbody><tr><td>表</td></tr></tbody></table>
(4) <TABLE><TBODY><TR><TD>表</TD></TR></TBODY></TABLE>
text/html は(1)の構造の(2)(3)(4)のような構造への修正をパーザに認めるようなもの。
application/xhtml+xml であればそれぞれ違う構造だと明示できる。
524 ：サ骨 ◆/IQ5000w ：02/05/09 10:10 ID:s+OSXbQK
525 ：Name_Not_Found：02/05/09 10:26 ID:1n6wOapm
>>517
> dtとddの関連性は要素の並び順でしか示されないので、
この前提を慣習と言っているのでは。
dt と dd の関連性は、最終的には内容の文章を読まなければ特定できないと思う。
並び順で推測する機能が UA にあってもいいと思うけれど
あくまで推測として扱われるべきものでしょ。
> dtとddの関連性は要素の並び順でしか示されないので、
この前提を慣習と言っているのでは。
dt と dd の関連性は、最終的には内容の文章を読まなければ特定できないと思う。
並び順で推測する機能が UA にあってもいいと思うけれど
あくまで推測として扱われるべきものでしょ。
526 ：Name_Not_Found：02/05/09 15:13 ID:Oe2HVafy
> この前提を慣習と言っているのでは。
そういう意味では慣習だろうけど、これはこの前の見出しレベルの扱いなんかと一緒で
遵守すべき慣習だと思う。言うなれば暗黙の諒解というか。
> dt と dd の関連性は、最終的には内容の文章を読まなければ特定できないと思う。
というのであれば、そもそも dt / dd という要素を定義する意味がない。
人間が文章の意味を理解できるのは当然。
コンピュータが素のテキストの意味を理解するのは困難だから、
コンピュータにテキストの意味を理解できるようにしよう、
というのがマーク付け言語の存在意義。
コンピュータが一意的に扱えるような規則がなかったら意味がない。
ちなみに、前々スレあたりにも書いたけど、HTML 2.0 のドラフトでは
dt / dd をこの順以外では出現できないようにする DTD も書かれていた。
これが最終的に採用されなかったのは、既存の文書に対する互換や
パーザの処理の簡化のため以上の意味はないと思う。
そういう意味では慣習だろうけど、これはこの前の見出しレベルの扱いなんかと一緒で
遵守すべき慣習だと思う。言うなれば暗黙の諒解というか。
> dt と dd の関連性は、最終的には内容の文章を読まなければ特定できないと思う。
というのであれば、そもそも dt / dd という要素を定義する意味がない。
人間が文章の意味を理解できるのは当然。
コンピュータが素のテキストの意味を理解するのは困難だから、
コンピュータにテキストの意味を理解できるようにしよう、
というのがマーク付け言語の存在意義。
コンピュータが一意的に扱えるような規則がなかったら意味がない。
ちなみに、前々スレあたりにも書いたけど、HTML 2.0 のドラフトでは
dt / dd をこの順以外では出現できないようにする DTD も書かれていた。
これが最終的に採用されなかったのは、既存の文書に対する互換や
パーザの処理の簡化のため以上の意味はないと思う。
527 ：Name_Not_Found：02/05/09 16:02 ID:1n6wOapm
> 遵守すべき慣習だと思う。言うなれば暗黙の諒解というか。
遵守すべき慣習ならそれはそれで "SHOULD" と書くのが仕様というもの。
暗黙の了解がまかり通るような仕様書は仕様書としての価値がない。
何のために仕様にこんな頁があるんだよ。
http://www.w3.org/TR/1999/REC-html401-19991224/conform.html
遵守すべき慣習ならそれはそれで "SHOULD" と書くのが仕様というもの。
暗黙の了解がまかり通るような仕様書は仕様書としての価値がない。
何のために仕様にこんな頁があるんだよ。
http://www.w3.org/TR/1999/REC-html401-19991224/conform.html
528 ：Name_Not_Found：02/05/09 16:47 ID:Oe2HVafy
> 遵守すべき慣習ならそれはそれで "SHOULD" と書くのが仕様というもの。
全てのケースを想定できるわけじゃなし。
どっちかと言えば、仕様書ではっきり禁止されていなければ
何でも罷り通るという発想の方が異常だと思うよ。
「blockquote でインデントする」「h1 で文字を大きくする」なんてのは、
そういう発想の賜物じゃないのか。
仕様書で禁止されていないんだからやってもいい、ではいけない。
勿論それでいい場合もあるんけど、この場合はよくないよ。
全てのケースを想定できるわけじゃなし。
どっちかと言えば、仕様書ではっきり禁止されていなければ
何でも罷り通るという発想の方が異常だと思うよ。
「blockquote でインデントする」「h1 で文字を大きくする」なんてのは、
そういう発想の賜物じゃないのか。
仕様書で禁止されていないんだからやってもいい、ではいけない。
勿論それでいい場合もあるんけど、この場合はよくないよ。
529 ：Name_Not_Found：02/05/09 18:14 ID:jsZ81leE
>>501はusability/specともにOKだろ? 確かにHistoricなHTML 2.0仕様書では、SHOULD NOTと記述されているが、それが削除されたということは、
幾分寛容になったということではないのか?
#見出し要素については同じことはいえません。見出し要素は"続く内容の見出し"と
記述されています。
幾分寛容になったということではないのか?
#見出し要素については同じことはいえません。見出し要素は"続く内容の見出し"と
記述されています。
530 ：Name_Not_Found：02/05/09 18:16 ID:1n6wOapm
> どっちかと言えば、仕様書ではっきり禁止されていなければ
> 何でも罷り通るという発想の方が異常だと思うよ。
その論理が理解できないんだが。俺が異常なのか？
禁止事項を禁止と書かず非推奨事項を非推奨と書かないのは、相当なヘタレ仕様書だぞ。
全部読めば細部まで余すことなく伝わる様に書くから仕様書なんだろ。
参考文献に挙がってもいない古いバージョンのしかもドラフト引っ張り出してきて
「～すべきだ(でない)」なんて言い出すような変な仕様聞いたこともないぞ。
> 何でも罷り通るという発想の方が異常だと思うよ。
その論理が理解できないんだが。俺が異常なのか？
禁止事項を禁止と書かず非推奨事項を非推奨と書かないのは、相当なヘタレ仕様書だぞ。
全部読めば細部まで余すことなく伝わる様に書くから仕様書なんだろ。
参考文献に挙がってもいない古いバージョンのしかもドラフト引っ張り出してきて
「～すべきだ(でない)」なんて言い出すような変な仕様聞いたこともないぞ。
531 ：Name_Not_Found：02/05/09 18:27 ID:TIj7Xa/i
532 ：Name_Not_Found：02/05/09 18:36 ID:TIj7Xa/i
>>525
<dl>
<dt>Ａ</dt>
<dt>Ｂ</dt>
<dt>Ｃ</dt>
<dt>Ｄ</dt>
<dd>Ａのこと</dd>
<dd>Ｂのこと</dd>
<dd>Ｃのこと</dd>
<dd>Ｄのこと</dd>
</dl>
とりあえずこんな記述はvalidであってもstrictじゃないはずだ。
<dl>
<dt>Ａ</dt>
<dt>Ｂ</dt>
<dt>Ｃ</dt>
<dt>Ｄ</dt>
<dd>Ａのこと</dd>
<dd>Ｂのこと</dd>
<dd>Ｃのこと</dd>
<dd>Ｄのこと</dd>
</dl>
とりあえずこんな記述はvalidであってもstrictじゃないはずだ。
533 ：茶文字 ◆xELvisFU ：02/05/09 18:46 ID:f18m2CaV
旧スレで同じような話になってたけど、dlにdtとddをそれぞれひとつ以上含むという案は
「やめにした」という経緯があるみたいだね。
>>531
<dl>
<dt>HTTP</dt>
<dl>HyperText Transfer Protocol</dl>
<dt>FTP</dt>
<dl>File Transfer Protocol</dl>
<dt>HP</dt>
<dl>HomePage</dl>
<dl>Hewlet Packerd</dl>
<dt>TELNET</dt>
</dl>
上記のように複数の定義から絞り込めていない(HP)場合や
未稿のためdlが存在しない(TELNET)もあり得るわけで、
各dtとdlがどのように結びついているかはマークアップからだけでは
判断しにくいんじゃないかな。
W3Cはあくまで好意として柔軟な記述が可能な仕様にしたんだろうけど、
文脈を読まなければマークアップの意図がわからないような仕様なら
仕様の側に問題があると思うんだがどうだろう。
「やめにした」という経緯があるみたいだね。
>>531
<dl>
<dt>HTTP</dt>
<dl>HyperText Transfer Protocol</dl>
<dt>FTP</dt>
<dl>File Transfer Protocol</dl>
<dt>HP</dt>
<dl>HomePage</dl>
<dl>Hewlet Packerd</dl>
<dt>TELNET</dt>
</dl>
上記のように複数の定義から絞り込めていない(HP)場合や
未稿のためdlが存在しない(TELNET)もあり得るわけで、
各dtとdlがどのように結びついているかはマークアップからだけでは
判断しにくいんじゃないかな。
W3Cはあくまで好意として柔軟な記述が可能な仕様にしたんだろうけど、
文脈を読まなければマークアップの意図がわからないような仕様なら
仕様の側に問題があると思うんだがどうだろう。
534 ：Name_Not_Found：02/05/09 19:02 ID:TIj7Xa/i
>>533
そのマークアップはひどいなと言ってみるテストｗ
そのマークアップはひどいなと言ってみるテストｗ
535 ：茶文字 ◆xELvisFU ：02/05/09 19:20 ID:f18m2CaV
>>534
いや、確かにひどいんだけどさ（ｗ
仮にdtはあとに続くddとワンセットになるものだ、というのが正論だとして、
しかし仕様書に明記されていないわけだからこれは不文律なんだよね。
tableでいうthead tfoot tbodyとかcol colgroupのように
dtなりddがどのグループに属するのか明示できれば
かなり見通しが持ちやすいと思うんだが。
あるいはhead -> bodyとかthead -> tfoot -> tbodyのように
出現順序を規定してしまうとか。
いや、確かにひどいんだけどさ（ｗ
仮にdtはあとに続くddとワンセットになるものだ、というのが正論だとして、
しかし仕様書に明記されていないわけだからこれは不文律なんだよね。
tableでいうthead tfoot tbodyとかcol colgroupのように
dtなりddがどのグループに属するのか明示できれば
かなり見通しが持ちやすいと思うんだが。
あるいはhead -> bodyとかthead -> tfoot -> tbodyのように
出現順序を規定してしまうとか。
536 ：Name_Not_Found：02/05/09 19:47 ID:1n6wOapm
> 文脈を読まなければマークアップの意図がわからないような仕様なら
> 仕様の側に問題があると思うんだがどうだろう。
「ここは定義語である」「ここは説明である」てことをマークアップできるじゃん。
dl/dt/dd ってそういう要素でしょ。それぞれの関係を記述できないのは仕様の問題？
HTML 自体、論理構造の厳密な記述を目的としているとは思えないんだが。
> 仕様の側に問題があると思うんだがどうだろう。
「ここは定義語である」「ここは説明である」てことをマークアップできるじゃん。
dl/dt/dd ってそういう要素でしょ。それぞれの関係を記述できないのは仕様の問題？
HTML 自体、論理構造の厳密な記述を目的としているとは思えないんだが。
537 ：茶文字 ◆xELvisFU ：02/05/09 20:13 ID:EdJyR1ML
>>536
ddは「説明である」ということをマークアップできるが、
「何の説明なのか」は明示できないでしょ。
だからtbodyやcolなんかを引き合いに出したわけで。
厳密な記述を求めているわけではなく、
むしろ各要素の所属を明確にできるという自由度を求めてるんだけど。
ddは「説明である」ということをマークアップできるが、
「何の説明なのか」は明示できないでしょ。
だからtbodyやcolなんかを引き合いに出したわけで。
厳密な記述を求めているわけではなく、
むしろ各要素の所属を明確にできるという自由度を求めてるんだけど。
>>535
あ、ddがdlになってるぞって意味でなｗ
>>537
一組のdtとddを含むdgroup(仮)要素があればわかりやすいのにな、
って話でかまわないんだよな？
せめてdl直下にdiv置ければ良かったんだけどね。
あ、ddがdlになってるぞって意味でなｗ
>>537
一組のdtとddを含むdgroup(仮)要素があればわかりやすいのにな、
って話でかまわないんだよな？
せめてdl直下にdiv置ければ良かったんだけどね。
539 ：茶文字 ◆xELvisFU ：02/05/09 20:27 ID:rLSNjSDk
>>538
うわ ほんまや＜dd -> dl
＞一組のdtとddを含むdgroup(仮)要素があればわかりやすいのにな、
＞ って話でかまわないんだよな？
あ、そういうこと。まとめてくれてありがとん。
うわ ほんまや＜dd -> dl
＞一組のdtとddを含むdgroup(仮)要素があればわかりやすいのにな、
＞ って話でかまわないんだよな？
あ、そういうこと。まとめてくれてありがとん。
540 ：Name_Not_Found：02/05/09 20:40 ID:1n6wOapm
<!ELEMENT DL - - (DGROUP)+ >
<!ELEMENT DGROUP O O (DT+, DD+) >
TBODY を参考にするとこんな感じか。確かに便利だろうな。
IE4 がそういう拡張をしていたら HTML4 に採用されてたかもな(w
<!ELEMENT DGROUP O O (DT+, DD+) >
TBODY を参考にするとこんな感じか。確かに便利だろうな。
IE4 がそういう拡張をしていたら HTML4 に採用されてたかもな(w
541 ：Name_Not_Found：02/05/09 21:43 ID:FxBw40l/
<!ELEMENT DL - - (DT, DD)+ >
DTとDDの関連付けなら素直にこうすれば？
今からでもHTMLのサブセットとして無理なく発表可能だと思うんだが？
DTとDDの関連付けなら素直にこうすれば？
今からでもHTMLのサブセットとして無理なく発表可能だと思うんだが？
542 ：Name_Not_Found：02/05/09 23:12 ID:kdNFJ8/9
543 ：Name_Not_Found：02/05/09 23:22 ID:jsZ81leE
>>541
どこかの仕様書で見た。HTML1のDraftだったか?
どこかの仕様書で見た。HTML1のDraftだったか?
544 ：Name_Not_Found：02/05/09 23:24 ID:jsZ81leE
HTML1のDraftのdtは空要素だったっけ? どこで見たのかな、思い出せない。
545 ：Name_Not_Found：02/05/10 07:50 ID:oxC2M8Dj
>>544
DT も DD も空要素になってるね。
http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
DL による会話のマークアップって、ひょっとして HTML4 が初出っぽい？
DT も DD も空要素になってるね。
http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
DL による会話のマークアップって、ひょっとして HTML4 が初出っぽい？
546 ：Name_Not_Found：02/05/10 14:17 ID:jZdpiWGJ
<dl>
<dt>strike</dt>
<dt>s</dt>
<dd>センターラインを引く</dd>
</dl>
ってstrictでないの？
<dt>strike</dt>
<dt>s</dt>
<dd>センターラインを引く</dd>
</dl>
ってstrictでないの？
547 ：Name_Not_Found：02/05/10 15:16 ID:oxC2M8Dj
548 ：Name_Not_Found：02/05/10 15:33 ID:uKN2F5fM
>>546
もちろんValidであるというのが前提で。
>>501以降の論点は、
「dtとddの関係をマークアップだけで明示できるか？」
って事。
それに沿った話をするならば、
同じdlの中に関係するddが無いdtを書かなければstrictと言える。
<dl>
<dt>strike</dt>
<dt>s</dt>
<dd>センターラインを引く</dd>
<dt>b</dt>
<!--ddは未記述…-->
<dt>table</dt>
<dd>表を書く</dd>
</dl>
とかなってるとstrictとは言えないだろう。
もちろんValidであるというのが前提で。
>>501以降の論点は、
「dtとddの関係をマークアップだけで明示できるか？」
って事。
それに沿った話をするならば、
同じdlの中に関係するddが無いdtを書かなければstrictと言える。
<dl>
<dt>strike</dt>
<dt>s</dt>
<dd>センターラインを引く</dd>
<dt>b</dt>
<!--ddは未記述…-->
<dt>table</dt>
<dd>表を書く</dd>
</dl>
とかなってるとstrictとは言えないだろう。
549 ：Name_Not_Found：02/05/10 19:24 ID:oxC2M8Dj
俺は「dtとddの関係をマークアップで明示する方法は
W3C の HTML4Strict では未定義である」って立場なんだが。
>>548 のソースは strict じゃないとまでは思わんな。
「紛らわしい日本語」みたいなもので
止めた方がいいとは思うが、それは strict とは全然別の文脈だわ。
W3C の HTML4Strict では未定義である」って立場なんだが。
>>548 のソースは strict じゃないとまでは思わんな。
「紛らわしい日本語」みたいなもので
止めた方がいいとは思うが、それは strict とは全然別の文脈だわ。
>>549
つまり、この場合は、ddが未記述なこと自体が問題なのではなくて、
ddが未記述であることによって、人間の読者が
「"b"と"table"が表を書く要素である」
と、誤解しやすくなってることが問題だと言ってるわけだよね？
つまり、この場合は、ddが未記述なこと自体が問題なのではなくて、
ddが未記述であることによって、人間の読者が
「"b"と"table"が表を書く要素である」
と、誤解しやすくなってることが問題だと言ってるわけだよね？
>>550
うん、そういうこと。
うん、そういうこと。
552 ：Name_Not_Found：02/05/10 23:16 ID:590sVV2H
>>548は自然言語だけでなく、マークアップ言語の範疇にも問題はあると思うな。
HTML4ではdtとddは対応関係にある。
dtとddに一対一、一対多、多対一、多対多はあっても、一対零はおかしいと思うよ。
HTML4ではdtとddは対応関係にある。
dtとddに一対一、一対多、多対一、多対多はあっても、一対零はおかしいと思うよ。
553 ：Name_Not_Found：02/05/11 01:09 ID:NRFxa9qo
http://www.win.ne.jp/~stij/column/rh990421.html
の
metaで作成者の名前を書くといけないって
あるけどなんで？
うちに書いているけど・・・strictじゃないのかなあ？
の
metaで作成者の名前を書くといけないって
あるけどなんで？
うちに書いているけど・・・strictじゃないのかなあ？
554 ：Name_Not_Found：02/05/11 01:22 ID:wjGAic6w
555 ：Name_Not_Found：02/05/11 01:22 ID:Hr0nYhHA
Wordで作ったまんまだと本名が出るからじゃないの？
556 ：Name_Not_Found：02/05/11 01:23 ID:FtzSZobF
保存する<ins>と</ins>
ｹｺｰﾝ
559 ：Name_Not_Found：02/05/11 01:54 ID:NRFxa9qo
そか
簡単なプロファイリングで分かりましたね・・
結婚おめでとう
簡単なプロファイリングで分かりましたね・・
結婚おめでとう
>>559
ありがとう…、幸せに……、なるか hoge ぇ！
ありがとう…、幸せに……、なるか hoge ぇ！
561 ：Name_Not_Found：02/05/11 09:57 ID:HllVVBBJ
野崎の日記にトンデモStrictサイトが載っててﾜﾛﾀ。
見出し要素であるべきところがp要素だったり。
見出し要素であるべきところがp要素だったり。
>>500
自己レスなんだけど、
DirectoryIndex index
Options +MultiViews
とすると、なんかディレクトリにアクセスしたときに
accept-type に関係なく application/xhtml+xml をよこされてしまう。
index 以外の名前なら大丈夫なんだけど。
何か間違ってるんだと思うけど、どこが違うんだろ。教えて偉いひと!
自己レスなんだけど、
DirectoryIndex index
Options +MultiViews
とすると、なんかディレクトリにアクセスしたときに
accept-type に関係なく application/xhtml+xml をよこされてしまう。
index 以外の名前なら大丈夫なんだけど。
何か間違ってるんだと思うけど、どこが違うんだろ。教えて偉いひと!
563 ：Name_Not_Found：02/05/11 17:57 ID:s/W2KvH/
コンテントネゴシエーションって
どうやるのよ？
検索したけど分からない。
おしえて下さいませ。
どうやるのよ？
検索したけど分からない。
おしえて下さいませ。
564 ：Name_Not_Found：02/05/11 18:13 ID:s/W2KvH/
foo.xml.xhtml.html
でfoo.xmlだとxmlでfoo.htmlを参照するとtext/htmlを返すの？？？？
でfoo.xmlだとxmlでfoo.htmlを参照するとtext/htmlを返すの？？？？
565 ：Name_Not_Found：02/05/11 19:21 ID:2aZ8R797
Apacheならhtaccessに、こうだな。
AddType "text/html;charset=iso-2022-jp" .html
AddType "application/xhtml+xml;charset=iso-2022-jp" .xhtml
AddType "application/xml;charset=iso-2022-jp" .xml
Options +MultiViews
次のはこの場合はこれができるといいんだけど、エラーかもしれん。
AddType "text/html;charset=iso-2022-jp" .xhtml
AddType "application/xhtml+xml;charset=iso-2022-jp" .xhtml
AddType "application/xml;charset=iso-2022-jp" .xhtml
Options +MultiViews
AddType "text/html;charset=iso-2022-jp" .html
AddType "application/xhtml+xml;charset=iso-2022-jp" .xhtml
AddType "application/xml;charset=iso-2022-jp" .xml
Options +MultiViews
次のはこの場合はこれができるといいんだけど、エラーかもしれん。
AddType "text/html;charset=iso-2022-jp" .xhtml
AddType "application/xhtml+xml;charset=iso-2022-jp" .xhtml
AddType "application/xml;charset=iso-2022-jp" .xhtml
Options +MultiViews
566 ：Name_Not_Found：02/05/11 20:25 ID:LZe8gr5f
参考までに。 An Httpd なら、[オプション]－[一般]に
[コンテントネゴシエーション]タブがある。
Apache の .htaccess の Options +MultiViews は
サーバによっては上書きできないように設定されていることがある。
その場合はかなり絶望的。管理者に設定の変更を頼むか、サーバを変えるか。
[コンテントネゴシエーション]タブがある。
Apache の .htaccess の Options +MultiViews は
サーバによっては上書きできないように設定されていることがある。
その場合はかなり絶望的。管理者に設定の変更を頼むか、サーバを変えるか。
567 ：Name_Not_Found：02/05/11 21:07 ID:zt5NJ3rh
>>565
後者の奴ってアリなの?
後者の奴ってアリなの?
568 ：Name_Not_Found：02/05/12 00:05 ID:r61hBS/w
ファイル名は
どうすればいいの？教えてくんでスマソ
どうすればいいの？教えてくんでスマソ
569 ：Name_Not_Found：02/05/12 00:15 ID:he4j1SKB
>>568
foo.html と foo.xhtml を両方うｐする。
つまり、Options +MultiViews っての記述すると、
../hoge/foo にアクセスしたときに、 foo.何とか を返すようになる。
「何とか」の部分(.html.ja とか .xhtml.en とか)がどうなるかは、
ブラウザの設定による。ブラウザが XHTML に対応していれば .xhtml が、
ブラウザが XHTML に非対応で HTML に対応していれば .html が送られてくる。
そういうのをコンテントネゴシエーションという。
foo.html と foo.xhtml を両方うｐする。
つまり、Options +MultiViews っての記述すると、
../hoge/foo にアクセスしたときに、 foo.何とか を返すようになる。
「何とか」の部分(.html.ja とか .xhtml.en とか)がどうなるかは、
ブラウザの設定による。ブラウザが XHTML に対応していれば .xhtml が、
ブラウザが XHTML に非対応で HTML に対応していれば .html が送られてくる。
そういうのをコンテントネゴシエーションという。
570 ：Name_Not_Found：02/05/12 00:27 ID:r61hBS/w
うーん
成功したのであろうか・Ｎ６．２はxhtml見れるけど
でもtext/htmlの方のファイルが来た。
Ｎ６．２じゃだめなのかな？
成功したのであろうか・Ｎ６．２はxhtml見れるけど
でもtext/htmlの方のファイルが来た。
Ｎ６．２じゃだめなのかな？
571 ：Name_Not_Found：02/05/12 02:03 ID:KizwtWta
話題反らして悪いんだけどさ、ある日突然その部分にだけスタイルを適用させたく
なった場合(漏れは<s>なのだが)、一番簡単なのはそこに<s>って書く方法だよね？
でもstrictじゃそれはイカンわけだよ。
しがなくCSSで.sとかなんとか付けて<li class="s">hogehoge</li>ってやるじゃない？
こういう風に一部分だけスタイル適用させたい場合ってやっぱこうしてるん？
記述量が増えてなぁんか矛盾してるなぁとか思っちゃうんだが。
ｽﾚ違いだったらｽﾏｿ。
なった場合(漏れは<s>なのだが)、一番簡単なのはそこに<s>って書く方法だよね？
でもstrictじゃそれはイカンわけだよ。
しがなくCSSで.sとかなんとか付けて<li class="s">hogehoge</li>ってやるじゃない？
こういう風に一部分だけスタイル適用させたい場合ってやっぱこうしてるん？
記述量が増えてなぁんか矛盾してるなぁとか思っちゃうんだが。
ｽﾚ違いだったらｽﾏｿ。
572 ：Name_Not_Found：02/05/12 02:13 ID:a+3n4+BK
>>571
あとから消去線を入れる必要ができたなら、del要素を使えばいいんじゃないかな。
あとから消去線を入れる必要ができたなら、del要素を使えばいいんじゃないかな。
573 ：Name_Not_Found：02/05/12 02:21 ID:AAHReq4B
>572
細かくてすまんが，「消去線を入れる必要ができたら」じゃなくて
「消去されたことを示す必要ができたら」だよね．
細かくてすまんが，「消去線を入れる必要ができたら」じゃなくて
「消去されたことを示す必要ができたら」だよね．
574 ：Name_Not_Found：02/05/12 02:26 ID:a+3n4+BK
575 ：Name_Not_Found：02/05/12 02:27 ID:KizwtWta
あ、そか。delがあったか。教えて君みたいになっちゃった。ｽﾏｿ!!
576 ：Name_Not_Found：02/05/12 08:06 ID:a7xteBfk
NN4では消されない罠
577 ：Name_Not_Found：02/05/12 10:25 ID:pDVEtW4g
578 ：Name_Not_Found：02/05/12 12:56 ID:eT+noWz0
application/xhtml+xml
なxhtmlのcssは
<link rel="stylesheet" href="foo.css" />
でなxlsとかなんとかつかうわけ？
なxhtmlのcssは
<link rel="stylesheet" href="foo.css" />
でなxlsとかなんとかつかうわけ？
579 ：Name_Not_Found：02/05/12 14:13 ID:aNXWaML/
なんでIDって日本語だめなんだろう
>>578
http://math.oheya.to/markup/TR/xhtml-media-types-1#application-xhtml-xml
によると
<?xml-stylesheet href="foo.css" type="text/css"?>
とかってするべきらしいね。
>>579
セグメントで飛ぶとき不都合があるからじゃないかな？
<h1><a id="かに日記">かに日記</a></h1>
ではURLに<a href="appendix.html#かに日記">という風に
日本語がはいってマズーになるからと思われ。
http://math.oheya.to/markup/TR/xhtml-media-types-1#application-xhtml-xml
によると
<?xml-stylesheet href="foo.css" type="text/css"?>
とかってするべきらしいね。
>>579
セグメントで飛ぶとき不都合があるからじゃないかな？
<h1><a id="かに日記">かに日記</a></h1>
ではURLに<a href="appendix.html#かに日記">という風に
日本語がはいってマズーになるからと思われ。
>>577
<del> を解釈するようになったのは、 NN4.76 とか 4.77 とか
とにかくそのへんのすごく最近の版らしいっす。
（未確認。ウチには 4.7 しかないし、
今更小数点以下100の位が違うだけの別版 NN4 なんて入れたくない
<del> を解釈するようになったのは、 NN4.76 とか 4.77 とか
とにかくそのへんのすごく最近の版らしいっす。
（未確認。ウチには 4.7 しかないし、
今更小数点以下100の位が違うだけの別版 NN4 なんて入れたくない
582 ：Name_Not_Found：02/05/12 15:11 ID:A14jjwUI
>>580
Unicode でエスケープして appendix.html#%u304B%u306B%u65E5%u8A18 にすれば
URI [RFC2396] の形式としては問題ない。
# システムによっては "かに日記.HTML" だってありえるわけだし。
Unicode でエスケープして appendix.html#%u304B%u306B%u65E5%u8A18 にすれば
URI [RFC2396] の形式としては問題ない。
# システムによっては "かに日記.HTML" だってありえるわけだし。
583 ：Name_Not_Found：02/05/12 18:34 ID:fqIxxBz3
584 ：茶文字 ◆xELvisFU ：02/05/12 18:45 ID:02qh9z67
585 ：Name_Not_Found：02/05/12 19:16 ID:BnMfwuu5
Strict的にはNN4は放置
586 ：Name_Not_Found：02/05/12 19:35 ID:kAbbuyWJ
NN4除けすらしないのが最強
588 ：Name_Not_Found：02/05/12 20:08 ID:kAbbuyWJ
別に仕様やDTDに反してるわけじゃないんだから、media="screen,print"とか
@importでNN4除けしても構わないと思うけど。
@importでNN4除けしても構わないと思うけど。
589 ：Name_Not_Found：02/05/12 20:08 ID:fqIxxBz3
デザインにこだわる→NN捨てという発想が生まれる。
例えばNNでdelやinsがシカトされようとも、ソースがきちんと
ダウンロードされていれば使い様もある。
きちんとマーク付けすればそれでよし。>>587がそのような
意味でコメントしているのなら同意。単に表示系で貶したいだけなら放置。
例えばNNでdelやinsがシカトされようとも、ソースがきちんと
ダウンロードされていれば使い様もある。
きちんとマーク付けすればそれでよし。>>587がそのような
意味でコメントしているのなら同意。単に表示系で貶したいだけなら放置。
590 ：Name_Not_Found：02/05/12 21:00 ID:O+sXeWeb
自分の場合、
del,insは互換性のためマークアップ的に無視されても自然言語的に解釈できるようにすべき。
まあ、あまり頻繁に使うものではないわな。初版のときに注意して記述すればな。
XHTML™ Basicには採用されていないし。
div,spanも互換性のため無視されても大丈夫にしてある。
>>587
IE5,NN4はレイアウトの点では無視されても大丈夫にしているので無視していますが、
文法チェッカだけ満点とってOKというのは現実にはなかなか。
"IE4でクラッシュした"とかいわれると対処せざるを得ないし。。。
del,insは互換性のためマークアップ的に無視されても自然言語的に解釈できるようにすべき。
まあ、あまり頻繁に使うものではないわな。初版のときに注意して記述すればな。
XHTML™ Basicには採用されていないし。
div,spanも互換性のため無視されても大丈夫にしてある。
>>587
IE5,NN4はレイアウトの点では無視されても大丈夫にしているので無視していますが、
文法チェッカだけ満点とってOKというのは現実にはなかなか。
"IE4でクラッシュした"とかいわれると対処せざるを得ないし。。。
591 ：Name_Not_Found：02/05/12 22:04 ID:zfFTzBNw
592 ：Name_Not_Found：02/05/12 23:21 ID:A14jjwUI
>>591
XHTML の場合はどうなんだろう？
XHTML の場合はどうなんだろう？
media="all"にすると
全部確認したのか？
import使うと 重くなる
とか言われて 面倒になって以来N４除けはしてないなあ
要素によてはMS P明朝とかいれて避けているけど
これも勝手にフォントスタイル決めるなっていわれそうだし。鬱
全部確認したのか？
import使うと 重くなる
とか言われて 面倒になって以来N４除けはしてないなあ
要素によてはMS P明朝とかいれて避けているけど
これも勝手にフォントスタイル決めるなっていわれそうだし。鬱
594 ：Name_Not_Found：02/05/13 03:12 ID:FSabf4Wv
<del><span class="del">hogehoge</span></del>
とか。
<del><strike>hogehoge</strike></del>
よかまだマシか。
とか。
<del><strike>hogehoge</strike></del>
よかまだマシか。
595 ：Name_Not_Found：02/05/13 03:52 ID:/bvd48mQ
>>594
http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
446-449あたりを参照。
真面目に過去の記述を訂正する場合は、NN4でも意味が通じるように注意しつつ、
del要素だけを使用し、打ち消し線とか小さい声（読み上げブラウザの場合）等を
ギャグとして使いたい場合は、<span class="whisper">とか、
<span class="real_intention">とかやるのが一番よろしいのでは。
http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
446-449あたりを参照。
真面目に過去の記述を訂正する場合は、NN4でも意味が通じるように注意しつつ、
del要素だけを使用し、打ち消し線とか小さい声（読み上げブラウザの場合）等を
ギャグとして使いたい場合は、<span class="whisper">とか、
<span class="real_intention">とかやるのが一番よろしいのでは。
596 ：茶文字 ◆xELvisFU ：02/05/13 04:11 ID:8hQrWX6W
>>593
UAの欠陥を顧慮していてはStrictな時代はこないんだと思う。
とりあえずこのスレ的には、重かろうが何だろうがStrictなら可ｗ
NN4.xを使うなとも切り捨てろとも言わないが、古いアプリであることは否めまい。
かつてMacが68KからPPCに移行したためにファットバイナリという形態の
アプリケーションが生まれたように、互換性を重視するならそのデメリットも
引き受けなさいってことなんだと思った。
# フォントの話は「UIは誰に主導権を渡すべきか」という話だからまた別か。
UAの欠陥を顧慮していてはStrictな時代はこないんだと思う。
とりあえずこのスレ的には、重かろうが何だろうがStrictなら可ｗ
NN4.xを使うなとも切り捨てろとも言わないが、古いアプリであることは否めまい。
かつてMacが68KからPPCに移行したためにファットバイナリという形態の
アプリケーションが生まれたように、互換性を重視するならそのデメリットも
引き受けなさいってことなんだと思った。
# フォントの話は「UIは誰に主導権を渡すべきか」という話だからまた別か。
597 ：Name_Not_Found：02/05/13 07:03 ID:kpc8Zwen
598 ：Name_Not_Found：02/05/13 07:41 ID:6Y1CRski
互換性に配慮したいなら Transitional が目的に合っている。
Transitional で <del><strike>hogehoge</strike></del> でいいんじゃないか？
Strict を選んでおいて互換性とか言うのってヘンな感じだ。
Transitional で <del><strike>hogehoge</strike></del> でいいんじゃないか？
Strict を選んでおいて互換性とか言うのってヘンな感じだ。
599 ：j君：02/05/13 07:49 ID:4/74HGM2
600 ：j君 ◆WvN53uu. ：02/05/13 07:50 ID:4/74HGM2
x AddEncoding application/xhtml+xml xhtml
。AddEncoding application/xhtml+xml
。AddEncoding application/xhtml+xml
601 ：j君 ◆WvN53uu. ：02/05/13 07:52 ID:4/74HGM2
だあ
600は無視599で合っています。
途中で送信してしまいました。連続カキコすいません。鬱だ。
600は無視599で合っています。
途中で送信してしまいました。連続カキコすいません。鬱だ。
602 ：Name_Not_Found：02/05/13 09:12 ID:zpe4kwqS
しかしapplication/xhtml+xmlを受け入れるＵＡなんて
あるのか？
あるのか？
603 ：Name_Not_Found：02/05/13 09:25 ID:0zlTVMZW
Form の <input type="button" ～> を使って無理やり <a href="～"> と同じようにリンクさせるって
アクセシビリティ的に許されると思われますか
アクセシビリティ的に許されると思われますか
604 ：Name_Not_Found：02/05/13 09:31 ID:6Y1CRski
>>602
Mozilla とか。リクエストの時に
Accept: application/xhtml+xml をしっかり吐いてくる。
>>603
許されるかどうかは使う人が決めることだけど、
スクリプトが使えない環境でリンク不可能なら、それだけアクセス性は落ちるよね。
<input type="submit"> にして form の action にリンク先を指定すれば
大きな問題は発生しないかな。
Mozilla とか。リクエストの時に
Accept: application/xhtml+xml をしっかり吐いてくる。
>>603
許されるかどうかは使う人が決めることだけど、
スクリプトが使えない環境でリンク不可能なら、それだけアクセス性は落ちるよね。
<input type="submit"> にして form の action にリンク先を指定すれば
大きな問題は発生しないかな。
605 ：Name_Not_Found：02/05/13 11:02 ID:6Y1CRski
606 ：Name_Not_Found：02/05/13 11:36 ID:T2Ig03n2
607 ：Name_Not_Found：02/05/13 11:38 ID:zpe4kwqS
でもnetscape6.2はAccept: application/xhtml+xml を
吐いてくれない。
吐いてくれない。
608 ：Name_Not_Found：02/05/13 11:54 ID:FD3r+kdI
j君のサイト教えれ（謎）
609 ：Name_Not_Found：02/05/13 12:26 ID:bs6NyBNL
<a href="～"><button>これでどうよ？ IEじゃ飛ばないけどな</button></a>
599 600 601は無視してください
あほ書きました
ごめんなさい
吊ってきます。
あほ書きました
ごめんなさい
吊ってきます。
611 ：Name_Not_Found：02/05/13 14:50 ID:PYbEhMAw
ところでbuttonというのは視覚情報を表しているわけではないのだろうか
612 ：Name_Not_Found：02/05/13 16:26 ID:tVjHPr0R
form周りは全部strictでないような気もする。
613 ：Name_Not_Found：02/05/13 17:34 ID:6Y1CRski
>>612
送信データや送信形式に関する情報の記述は非Strict的ですか。
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/intro/intro.html#h-2.2
> HTMLは著者に次の手段を提供する。
> (略)
> ・ 情報検索、予約、商品の注文などの遠隔サービスのトランザクションに用いるフォームを設計すること。
まー確かに一般的な論理要素とは違うと思うけど
基本的な発想はそう逸脱するようなものではないと思うな。
input 要素にしても button 要素にしても、
それが「ある形式のコントロールである」ということであって、
コントロールの形状を指定するようなものではないし。
# size 属性とかあるけどね。
送信データや送信形式に関する情報の記述は非Strict的ですか。
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/intro/intro.html#h-2.2
> HTMLは著者に次の手段を提供する。
> (略)
> ・ 情報検索、予約、商品の注文などの遠隔サービスのトランザクションに用いるフォームを設計すること。
まー確かに一般的な論理要素とは違うと思うけど
基本的な発想はそう逸脱するようなものではないと思うな。
input 要素にしても button 要素にしても、
それが「ある形式のコントロールである」ということであって、
コントロールの形状を指定するようなものではないし。
# size 属性とかあるけどね。
614 ：Name_Not_Found：02/05/13 17:42 ID:P3JgZcm4
bottun要素はinput要素に比べて物理要素っぽいな。
615 ：Name_Not_Found：02/05/13 18:05 ID:tKPVVIAQ
物理要素よりというより、CSSにvisualやauralの扱いがあるのと
似たようなもんじゃねえの？
ま、使いたくなきゃモジュール外しなさいってこった
似たようなもんじゃねえの？
ま、使いたくなきゃモジュール外しなさいってこった
616 ：Name_Not_Found：02/05/13 20:57 ID:hT5hBkfx
＞単にボタン型にしたいってだけなら、 A 要素に CSS を適用させるのがこのスレ的か。
ありがとう！！！ この手で行きます。
ありがとう！！！ この手で行きます。
617 ：Name_Not_Found：02/05/13 21:38 ID:UOup7QGO
>>592
HTML 4.01 には「name/id の値はアスキーのみ」[1] とあるけど、
これは名前文字の定義から自明と思われ。
で、XHTML 1.0/1.1/Basic には特に言及がないが、XHTML 1.0 SE の草案には
「HTML 4.01 との互換性を考慮するなら name/id はアスキーのみとすべき」
[2] とある。
結局、XML として記述する場合には日本語を使って構わないということになるかと。
まあ当然と言えば当然だけど。
[1] ttp://www.w3.org/TR/html4/struct/links.html#idx-anchor-6
[2] ttp://www.w3.org/TR/2001/WD-xhtml1-20011004/#C_8
HTML 4.01 には「name/id の値はアスキーのみ」[1] とあるけど、
これは名前文字の定義から自明と思われ。
で、XHTML 1.0/1.1/Basic には特に言及がないが、XHTML 1.0 SE の草案には
「HTML 4.01 との互換性を考慮するなら name/id はアスキーのみとすべき」
[2] とある。
結局、XML として記述する場合には日本語を使って構わないということになるかと。
まあ当然と言えば当然だけど。
[1] ttp://www.w3.org/TR/html4/struct/links.html#idx-anchor-6
[2] ttp://www.w3.org/TR/2001/WD-xhtml1-20011004/#C_8
618 ：Name_Not_Found：02/05/13 22:20 ID:6Y1CRski
> これは名前文字の定義から自明と思われ。
HTML4 の A 要素の name 属性の値は NMTOKEN ではなく CDATA だったりする…。
なんの意図かあってわざわざ CDATA なんだろう。
HTML4 の A 要素の name 属性の値は NMTOKEN ではなく CDATA だったりする…。
なんの意図かあってわざわざ CDATA なんだろう。
619 ：Name_Not_Found：02/05/13 22:23 ID:f9J67HWs
inputもaもStrictなんだしアクセシビリティは一緒！ なんてのは乱暴だな。
利用者に対してサーバへリクエストを要求する手段を提供するのが
フォーム要素なんだから、単なるリンクにinputを使うのはStrict的ではないだろ。
利用者に対してサーバへリクエストを要求する手段を提供するのが
フォーム要素なんだから、単なるリンクにinputを使うのはStrict的ではないだろ。
620 ：Name_Not_Found：02/05/13 22:27 ID:6Y1CRski
> 単なるリンクにinputを使うのはStrict的ではないだろ。
には同意だけれども
> 利用者に対してサーバへリクエストを要求する
のは普通のリンクも同じ事をしていると思う。
には同意だけれども
> 利用者に対してサーバへリクエストを要求する
のは普通のリンクも同じ事をしていると思う。
622 ：Name_Not_Found：02/05/13 23:40 ID:f9J67HWs
http://math.oheya.to/markup/TR/xhtml-media-types-1
によりますとxhtml1.1のmime-typeはtext/xhtmはnot shouldなのですが
ようするにhtmlとして見せたいならxhtml1.0使うしかないですか？
によりますとxhtml1.1のmime-typeはtext/xhtmはnot shouldなのですが
ようするにhtmlとして見せたいならxhtml1.0使うしかないですか？
624 ：Name_Not_Found：02/05/14 15:02 ID:yXzug0Ov
625 ：Name_Not_Found：02/05/14 15:13 ID:9Jhsn4LW
>>623
「SHOULD NOT」は RFC2119 のとおりに解される。
http://www.asahi-net.or.jp/~sd5a-ucd/rfc-j/rfc-2119j.html
>「SHOULD NOT」あるいは「NOT RECOMMENDED」は、ある特定の行動が望ましいかまたは有意義なのだと言いうる妥当な理由が存在するような状況下で、全ての意味が理解され、また慎重に判断された場合、この語で否定されている行動を行っても構わないということになります。
例えば、プレーンテキストとして扱う意図を伝えるために
html4 だろうと xhtml だろうと text/plain にすることはよくあるよね。
あえて text/plain にする十分な理由があるわけで、問題ない。
xhtml1.1 を html として扱わせたいなら text/html でいい。
ポイントは html として扱わせる以上 xhtml, xml としての情報が伝わらなくなること。
「SHOULD NOT」は RFC2119 のとおりに解される。
http://www.asahi-net.or.jp/~sd5a-ucd/rfc-j/rfc-2119j.html
>「SHOULD NOT」あるいは「NOT RECOMMENDED」は、ある特定の行動が望ましいかまたは有意義なのだと言いうる妥当な理由が存在するような状況下で、全ての意味が理解され、また慎重に判断された場合、この語で否定されている行動を行っても構わないということになります。
例えば、プレーンテキストとして扱う意図を伝えるために
html4 だろうと xhtml だろうと text/plain にすることはよくあるよね。
あえて text/plain にする十分な理由があるわけで、問題ない。
xhtml1.1 を html として扱わせたいなら text/html でいい。
ポイントは html として扱わせる以上 xhtml, xml としての情報が伝わらなくなること。
626 ：j君 ◆WvN53uu. ：02/05/14 18:16 ID:3PIVrqic
なるほど。xhtml1.0に戻したちゃった。
神経過敏。
神経過敏。
627 ：Name_Not_Found：02/05/14 21:43 ID:QkaopmtY
>>626
頭悪そう。
頭悪そう。
628 ：Name_Not_Found：02/05/14 23:02 ID:hvyyx3x7
input,buttonはbrと同様、本来は物理的要素だが、論理的要素として代用できる要素と考えられる。
次版のXHTML2.0の片鱗を見せるXFormの草案では完全な論理的要素になっています。
したがってfontほどlooseではなく、strictの領域には十分含まれ、適切な使用ならばまったく問題はない。
しかしXHTML Host Modulesに含まれるa要素のほうが含まれないinputよりアクセシビリティが高いのは明らか。
a要素で代用できるところはa要素で記述すべき。
次版のXHTML2.0の片鱗を見せるXFormの草案では完全な論理的要素になっています。
したがってfontほどlooseではなく、strictの領域には十分含まれ、適切な使用ならばまったく問題はない。
しかしXHTML Host Modulesに含まれるa要素のほうが含まれないinputよりアクセシビリティが高いのは明らか。
a要素で代用できるところはa要素で記述すべき。
629 ：Name_Not_Found：02/05/14 23:25 ID:9Jhsn4LW
XHTML Host Modules て Core モジュールのこと？ 違ってたらおしえて。
630 ：Name_Not_Found：02/05/15 12:01 ID:nvbDaWc9
>>628
> したがって
XForms草案の内容がどうであれ、(X)HTMLのinputやbuttonはXFormsじゃない。
一方が論理要素だから他方もなんて一緒くたに考えるのは危険だと思うぞ。
草案にXHTML2.0の片鱗が見えるとかいっても、単なる主観でしょ？
> 適切な使用ならばまったく問題はない。
自体は正論だと思うが。
# SVGって物理要素だらけでlooseとかって言われちゃうんだろうかと思った。
> したがって
XForms草案の内容がどうであれ、(X)HTMLのinputやbuttonはXFormsじゃない。
一方が論理要素だから他方もなんて一緒くたに考えるのは危険だと思うぞ。
草案にXHTML2.0の片鱗が見えるとかいっても、単なる主観でしょ？
> 適切な使用ならばまったく問題はない。
自体は正論だと思うが。
# SVGって物理要素だらけでlooseとかって言われちゃうんだろうかと思った。
631 ：Name_Not_Found：02/05/15 12:45 ID:F9LIidfo
>>629
XHTML Host Modules って語は聞いたことない。
XHTML Host Language ではなく?
>>630
> SVG って物理要素だらけで loose とかって言われちゃうんだろうかと思った。
SVG は物理表現のための言語なのだから strict でしょうよ
とネタにマジレスしてみるテスト。
むしろ SVG の論理要素の方が loose なような(w
つーか個人的には MathML の物理要素の方が気になる。
一概に loose とは言い切れない部分もあるし。
XHTML Host Modules って語は聞いたことない。
XHTML Host Language ではなく?
>>630
> SVG って物理要素だらけで loose とかって言われちゃうんだろうかと思った。
SVG は物理表現のための言語なのだから strict でしょうよ
とネタにマジレスしてみるテスト。
むしろ SVG の論理要素の方が loose なような(w
つーか個人的には MathML の物理要素の方が気になる。
一概に loose とは言い切れない部分もあるし。
632 ：Name_Not_Found：02/05/15 15:19 ID:tkis821s
MathMLの論理要素のみをMathMLとして
物理要素はXSLのようにXSLTの結果としてのみ存在すべきだ。と思う。
私見だが
XHTML+SVG+MAthMLなんぞ全然Strictではない。
XHTML+SMILなど論外。
物理要素はXSLのようにXSLTの結果としてのみ存在すべきだ。と思う。
私見だが
XHTML+SVG+MAthMLなんぞ全然Strictではない。
XHTML+SMILなど論外。
633 ：Name_Not_Found：02/05/15 15:26 ID:DQ/UfQo5
map要素にp要素とかいれていいの？
634 ：Name_Not_Found：02/05/15 16:11 ID:nvbDaWc9
>>633
いい。奨められて(※)さえいる。
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/objects.html#h-13.6.1
※ pを入れることではなく、a要素を使うことが。
いい。奨められて(※)さえいる。
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/objects.html#h-13.6.1
※ pを入れることではなく、a要素を使うことが。
635 ：Name_Not_Found：02/05/15 16:40 ID:ebqbg8TB
>>632
> 私見だが XHTML+SVG+MathML なんぞ全然 Strict ではない。
んなこたーないと思う。
単に object で取り込むか、名前空間を変えて直接的に表現するかの違い。
<h1><img .../></h1> と <h1><svg:svg>...</svg:svg></h1> なんて大差ない。
HTML として扱いたければ XML の名前空間に属しているマーク付けだけを
抜き出せばいいんだから。
> 私見だが XHTML+SVG+MathML なんぞ全然 Strict ではない。
んなこたーないと思う。
単に object で取り込むか、名前空間を変えて直接的に表現するかの違い。
<h1><img .../></h1> と <h1><svg:svg>...</svg:svg></h1> なんて大差ない。
HTML として扱いたければ XML の名前空間に属しているマーク付けだけを
抜き出せばいいんだから。
636 ：Name_Not_Found：02/05/15 17:00 ID:m7LY3oJa
某エディタのマクロの解説ページを作ってるんだけど
そのエディタのマクロのなかに､いわゆる半角ｶﾅがあって困ってるんだ。
当然､全角に変換したんじゃ、そのマクロは動かないしね。
どうしたもんだろ？
ちなみに、htmlはShift-JISで書いてます。
そのエディタのマクロのなかに､いわゆる半角ｶﾅがあって困ってるんだ。
当然､全角に変換したんじゃ、そのマクロは動かないしね。
どうしたもんだろ？
ちなみに、htmlはShift-JISで書いてます。
637 ： ：02/05/15 17:17 ID:DhGHijzL
>636
半角カナの使用と strict であることは両立すると思うんだけど
半角カナの使用と strict であることは両立すると思うんだけど
638 ：Name_Not_Found：02/05/15 18:37 ID:rEQ8xAVc
>>635
俺的には、
<h1><img .../></h1> も <h1><svg:svg>...</svg:svg></h1>
CSS3のreplaceだかcontentでやることだと思うな。
図であることに意味がある場合を除いては<img>でも<svg:svg>でも問題ない
というか、むしろそのために使うべき。
俺的には、
<h1><img .../></h1> も <h1><svg:svg>...</svg:svg></h1>
CSS3のreplaceだかcontentでやることだと思うな。
図であることに意味がある場合を除いては<img>でも<svg:svg>でも問題ない
というか、むしろそのために使うべき。
639 ：Name_Not_Found：02/05/15 18:55 ID:eWY7SrND
XHTML Host Modulesとはhtmlをルート要素にする文書仕様が必ず含まなければならないモジュール群です。
640 ：Name_Not_Found：02/05/15 19:21 ID:nvbDaWc9
641 ：Name_Not_Found：02/05/15 19:39 ID:cwMYjspA
>>640
>>631 の言う通り XHTML Host Language module のことではないかと思われ。
http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_document_type
ちなみに、こっちでは似たようなものが core modules と呼ばれているんだが
実はどう違うか(または同じなのか)解らなかったりする。鬱だ。
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#sec_5.2.
>>631 の言う通り XHTML Host Language module のことではないかと思われ。
http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_document_type
ちなみに、こっちでは似たようなものが core modules と呼ばれているんだが
実はどう違うか(または同じなのか)解らなかったりする。鬱だ。
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#sec_5.2.
643 ：Name_Not_Found：02/05/15 20:00 ID:cwMYjspA
>>636
スマン、何が問題なのかわからんのだが…Shift-JIS は半角カナを
認めているコードで、HTMLはそのShift-JISを認めているのだから
素直に半角カナを書けば？
まぁ、>>642 の言う通り、文字参照で書いた方がベターなことは確かだが。
スマン、何が問題なのかわからんのだが…Shift-JIS は半角カナを
認めているコードで、HTMLはそのShift-JISを認めているのだから
素直に半角カナを書けば？
まぁ、>>642 の言う通り、文字参照で書いた方がベターなことは確かだが。
644 ：Name_Not_Found：02/05/15 20:51 ID:ebqbg8TB
>>638
それは同意。
>>641
「XHTML をホストにした文書」っていうのは
<?xml version="1.0" ?>
<html xmlns="http://www.w3.org/1999/xhtml">
...
</html>
という感じのやつ。読んで字の如く XHTML の要素がホストの文書。
ただし、「この文書のホスト言語は XHTML です」と言い張るためには
最低限含まれていなければならないモジュールがある、と。
これを XHTML Basic 勧告では XHTML Host Language module と呼んでいるけど、
M12N of XHTML では特別名前を付けてモジュールと表現している訳ではなく、
ただ単に「XHTML Host Language は須くこれらのモジュールを含むべし」としているだけ。
ちなみにそこで必須とされているモジュールは core modules そのもの。
という感じでよろしいでしょうか。
それは同意。
>>641
「XHTML をホストにした文書」っていうのは
<?xml version="1.0" ?>
<html xmlns="http://www.w3.org/1999/xhtml">
...
</html>
という感じのやつ。読んで字の如く XHTML の要素がホストの文書。
ただし、「この文書のホスト言語は XHTML です」と言い張るためには
最低限含まれていなければならないモジュールがある、と。
これを XHTML Basic 勧告では XHTML Host Language module と呼んでいるけど、
M12N of XHTML では特別名前を付けてモジュールと表現している訳ではなく、
ただ単に「XHTML Host Language は須くこれらのモジュールを含むべし」としているだけ。
ちなみにそこで必須とされているモジュールは core modules そのもの。
という感じでよろしいでしょうか。
>>644
言葉遊びレベルの書き込みに丁寧な解説サンクス。
言葉遊びレベルの書き込みに丁寧な解説サンクス。
647 ：Name_Not_Found：02/05/15 23:44 ID:dvLGuGYZ
>>634
そういや
<p>
<map id="sage">
<p><a href="#contents">次</a>
<a href="./index.html">索引</a>
</p>
</map>
</p>
みたいにp要素でp要素をmap要素をはさんで囲んでいいのかな？
というかよくてもstrictかな？
<p><del><p>hoge</p></del></p>
はダメだけど、これはどうだろ？
そういや
<p>
<map id="sage">
<p><a href="#contents">次</a>
<a href="./index.html">索引</a>
</p>
</map>
</p>
みたいにp要素でp要素をmap要素をはさんで囲んでいいのかな？
というかよくてもstrictかな？
<p><del><p>hoge</p></del></p>
はダメだけど、これはどうだろ？
648 ：Name_Not_Found：02/05/15 23:53 ID:pKK9obOk
649 ：Name_Not_Found：02/05/16 00:15 ID:MVfWRhfO
650 ：Name_Not_Found：02/05/16 00:56 ID:AlRLMhCY
>>649
> しかるに HTML Validation Service はパスするんだよね
ありゃ妥当性しか検証していませんから。
XHTML なら <a><em><a>hoge</a></em></a> だって valid ですし。
> しかるに HTML Validation Service はパスするんだよね
ありゃ妥当性しか検証していませんから。
XHTML なら <a><em><a>hoge</a></em></a> だって valid ですし。
651 ：Name_Not_Found：02/05/16 01:28 ID:MVfWRhfO
でも
ここの例題
http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html
どう見てもpにpをいれてるんすよ。
w3c的にはOKみたいっすよ。
【例】
<P>
<OBJECT data="navbar.png" type="image/png" usemap="#map1">
<OBJECT data="navbar.gif" type="image/gif" usemap="#map1">
<MAP name="map1">
<P>Navigate the site:
<A href="guide.html" shape="rect" coords="0,0,118,28">Access Guide</a> |
<A href="shortcut.html" shape="rect" coords="118,0,184,28">Go</A> |
<A href="search.html" shape="circle" coords="184,200,60">Search</A> |
<A href="top10.html" shape="poly" coords="276,0,276,28,100,200,50,50,276,0">Top Ten</A>
</MAP>
</OBJECT>
</OBJECT>
ここの例題
http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html
どう見てもpにpをいれてるんすよ。
w3c的にはOKみたいっすよ。
【例】
<P>
<OBJECT data="navbar.png" type="image/png" usemap="#map1">
<OBJECT data="navbar.gif" type="image/gif" usemap="#map1">
<MAP name="map1">
<P>Navigate the site:
<A href="guide.html" shape="rect" coords="0,0,118,28">Access Guide</a> |
<A href="shortcut.html" shape="rect" coords="118,0,184,28">Go</A> |
<A href="search.html" shape="circle" coords="184,200,60">Search</A> |
<A href="top10.html" shape="poly" coords="276,0,276,28,100,200,50,50,276,0">Top Ten</A>
</MAP>
</OBJECT>
</OBJECT>
652 ：Name_Not_Found：02/05/16 02:19 ID:4WmGzGEu
>>651
p - object - pは正統でしょ。
A要素型みたいに例外となっている↓ならともかく、
<!ELEMENT A - - (%inline;)* -(A) -- anchor -->
P要素型はDTDでも別に禁止されていないし↓
<!ELEMENT P - O (%inline;)* -- paragraph -->
p - object - pは正統でしょ。
A要素型みたいに例外となっている↓ならともかく、
<!ELEMENT A - - (%inline;)* -(A) -- anchor -->
P要素型はDTDでも別に禁止されていないし↓
<!ELEMENT P - O (%inline;)* -- paragraph -->
653 ：Name_Not_Found：02/05/16 07:55 ID:8UmIm1Be
フォントの大きさが
H1>h2>h3>h4>h5>h6
でないとだめっすかね？h2が日本語で
h3がアスキー文字で、見た感じが違うから
スタイルをh3の方を大きくしてるんですけどねえ・・。
H1>h2>h3>h4>h5>h6
でないとだめっすかね？h2が日本語で
h3がアスキー文字で、見た感じが違うから
スタイルをh3の方を大きくしてるんですけどねえ・・。
654 ：Name_Not_Found：02/05/16 08:26 ID:oGK0oWVA
655 ：Name_Not_Found：02/05/16 09:22 ID:s8AR+n1b
>>653
654の言ってるとおり、スタイル指定はHTMLとは直接関係ないからスレ違いでは。
とりあえず、「h2が日本語でh3がアスキー文字」という自己ルールに依存した
スタイル指定は、応用が利きにくいということは言えると思う。
654の言ってるとおり、スタイル指定はHTMLとは直接関係ないからスレ違いでは。
とりあえず、「h2が日本語でh3がアスキー文字」という自己ルールに依存した
スタイル指定は、応用が利きにくいということは言えると思う。
656 ：Name_Not_Found：02/05/16 13:18 ID:25kErxqS
すれ違いってことないんでは？
IE以外はきかないcssはダメとか
display:blockはテキスト方向との兼ね合いで
ダメとかStrictな精神にも関係あるかと。
IE以外はきかないcssはダメとか
display:blockはテキスト方向との兼ね合いで
ダメとかStrictな精神にも関係あるかと。
あら
ime.nuはセグメント
消しちゃうのね。
ttp://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.3
です。 li{display:inline;}でナビゲーションバー作ってたけど
どうしようかなあ・・ちゃんと考えればいいのかな。
ime.nuはセグメント
消しちゃうのね。
ttp://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.3
です。 li{display:inline;}でナビゲーションバー作ってたけど
どうしようかなあ・・ちゃんと考えればいいのかな。
660 ：Name_Not_Found：02/05/16 14:17 ID:oGK0oWVA
>>1
> Strict な HTML(*) について語るスレッド Version 3.2
いっそ W3C(あるいは標準化団体全般) による技術全部ひっくるめた
「Web標準スレ」とか作った方がいいのかもと思った。
次スレから改称＆話題拡張でもいいけど。
>>659
> セグメント
それはフラグメント。
> Strict な HTML(*) について語るスレッド Version 3.2
いっそ W3C(あるいは標準化団体全般) による技術全部ひっくるめた
「Web標準スレ」とか作った方がいいのかもと思った。
次スレから改称＆話題拡張でもいいけど。
>>659
> セグメント
それはフラグメント。
661 ：Name_Not_Found：02/05/16 14:55 ID:jlHa/JDj
662 ：Name_Not_Found：02/05/16 17:53 ID:n3TIaETC
どっちにせよ、テキスト方向は
unicode-bidiとdirectionで指定できる。
指定しなくても
unicodeにちゃんと対応したブラウザなら
utf-8とかで書いてれば、言語によって方向を変えてくれるし
unicode-bidiとdirectionで指定できる。
指定しなくても
unicodeにちゃんと対応したブラウザなら
utf-8とかで書いてれば、言語によって方向を変えてくれるし
663 ：Name_Not_Found：02/05/16 17:57 ID:ra5aouqI
IEで保存したら、XHTML 1.0 Strictで書いたページでも、
全て強制的に HTML 4.0 Transitional に書き直されてしまうのか（鬱
普段、IEでページを保存なんてしないから、「お前のページTransitionalじゃん」って
友人から、勘違いこみの指摘されるまで、知らんかったよ（鬱
全て強制的に HTML 4.0 Transitional に書き直されてしまうのか（鬱
普段、IEでページを保存なんてしないから、「お前のページTransitionalじゃん」って
友人から、勘違いこみの指摘されるまで、知らんかったよ（鬱
664 ：Name_Not_Found：02/05/16 18:18 ID:ulBj8R2L
そういうときは、「ソースの表示」して、メモ帳などで「保存」
665 ：Name_Not_Found：02/05/16 18:21 ID:oGK0oWVA
>>664
「Webページ、HTML のみ」でソースのまま保存しない？
「Webページ、HTML のみ」でソースのまま保存しない？
私もソースを保存します。
エンコードとかいじちゃうと
別物になっちゃうしね
ソースでとるのがいいや。
＞＞６５８
まあUAはDISPLAYプロパティを無視していいことになっているし、
W3C的に多用はいかんよってこともあるだろね。
ブロックはブロック、インラインはインラインでってことでしょう。
>>659
floatで流せば同じようになるよ。N4だとあちこちに流れるけどｗ
でもまあ、li要素はmenu要素の中ではインラインのように振舞うことも
あるわけで、display:inlineもそもまでわるいとは言えないと思う。
実際menuの中のliを横に並べて表示させるAUは知らないけど・・。
エンコードとかいじちゃうと
別物になっちゃうしね
ソースでとるのがいいや。
＞＞６５８
まあUAはDISPLAYプロパティを無視していいことになっているし、
W3C的に多用はいかんよってこともあるだろね。
ブロックはブロック、インラインはインラインでってことでしょう。
>>659
floatで流せば同じようになるよ。N4だとあちこちに流れるけどｗ
でもまあ、li要素はmenu要素の中ではインラインのように振舞うことも
あるわけで、display:inlineもそもまでわるいとは言えないと思う。
実際menuの中のliを横に並べて表示させるAUは知らないけど・・。
ｘ AUは知らないけど
○ User Agentは知らないけど
○ User Agentは知らないけど
668 ：Name_Not_Found：02/05/16 21:43 ID:oGK0oWVA
669 ：Name_Not_Found：02/05/16 23:18 ID:s8AR+n1b
>>668
「何の影響もない」ってことはないと思いますが。
UAに対してはともかく、対人的にはスタイルで意図を伝えやすくしてる部分も
あるわけで、スタイルぜんぶ無視される（ブラウザのデフォルトスタイルで
表示される）のならともかく、特定のスタイルだけ無視されると、見づらく
なったり、誤解を招きやすくなったりすることはあり得るのでは。
「何の影響もない」ってことはないと思いますが。
UAに対してはともかく、対人的にはスタイルで意図を伝えやすくしてる部分も
あるわけで、スタイルぜんぶ無視される（ブラウザのデフォルトスタイルで
表示される）のならともかく、特定のスタイルだけ無視されると、見づらく
なったり、誤解を招きやすくなったりすることはあり得るのでは。
670 ：Name_Not_Found：02/05/17 00:46 ID:BQXPfEjx
>>669
ユーザ側でスタイルシートを指定されていれば…など
考えればきりが無い。
これはいくらサイト制作者側が熟考したところで対策のしようがないし、
そういう自体がおこった場合にはユーザ側でスタイルシートOffにしる！
とするしかないと思った。
微妙に擦れ違いだと思った＜俺。ひとまず>>668に同意。
ユーザ側でスタイルシートを指定されていれば…など
考えればきりが無い。
これはいくらサイト制作者側が熟考したところで対策のしようがないし、
そういう自体がおこった場合にはユーザ側でスタイルシートOffにしる！
とするしかないと思った。
微妙に擦れ違いだと思った＜俺。ひとまず>>668に同意。
671 ：Name_Not_Found：02/05/17 11:09 ID:VsF5LSus
同じページにh1を２個出していいです？
次のページにもっていかずに
同じページにしようとして、あわせるほうのページをｈ１から
丸々<address>やナビゲーションバーを抜いてこぴったんすけど
だめっすかね？
次のページにもっていかずに
同じページにしようとして、あわせるほうのページをｈ１から
丸々<address>やナビゲーションバーを抜いてこぴったんすけど
だめっすかね？
672 ：Name_Not_Found：02/05/17 11:49 ID:HoJ5nI0a
>>671
なぜダメだと思うの？
なぜダメだと思うの？
673 ：Name_Not_Found：02/05/17 11:49 ID:1TJntVRZ
>>671
それだとページ全体の見出し（題名というべきか）がなくてわかりにくいので、
見出し全体のレベルをひとつ落として（h1→h2、h2→h3……という風に）、
題名をh1としてマークアップした方がいいんじゃないかと思います。
まあ、題名はtitle要素に書けばいい、という考え方もあるかもしれないけど。
それだとページ全体の見出し（題名というべきか）がなくてわかりにくいので、
見出し全体のレベルをひとつ落として（h1→h2、h2→h3……という風に）、
題名をh1としてマークアップした方がいいんじゃないかと思います。
まあ、題名はtitle要素に書けばいい、という考え方もあるかもしれないけど。
674 ：Name_Not_Found：02/05/18 00:35 ID:w9ia1zlc
<body>
<h1>写真</h1>
<div><img … /></div>
</body>
※body要素だけ抜粋
これってStrictですか？
やっぱ、<div>要素じゃなくて<p>要素を使うべきですか？
<h1>写真</h1>
<div><img … /></div>
</body>
※body要素だけ抜粋
これってStrictですか？
やっぱ、<div>要素じゃなくて<p>要素を使うべきですか？
675 ：Name_Not_Found：02/05/18 00:44 ID:jQloVuPg
<img … />の位置付けは何ですか？
それによって変わるのでは。
それによって変わるのでは。
676 ：674：02/05/18 00:57 ID:w9ia1zlc
ごめんなさい。
頭が混乱してきたので、もう一度本を読み直してみます…
…Strictって難しい
頭が混乱してきたので、もう一度本を読み直してみます…
…Strictって難しい
677 ：Name_Not_Found：02/05/18 02:36 ID:s9byT/kr
テーブルにキャプションを付けるように
画像にキャプションを付けるマークアップはありますか?
画像にキャプションを付けるマークアップはありますか?
678 ：Name_Not_Found：02/05/18 02:50 ID:5mLmrWjW
>>677
定義リストでも使っとけ。
定義リストでも使っとけ。
679 ：Name_Not_Found：02/05/18 06:10 ID:UV8BXz2L
>>677
1x1の表を作れ。
1x1の表を作れ。
680 ：Name_Not_Found：02/05/18 07:25 ID:uBetcHZa
キノトロープも、テーブルレイアウト。
文の補足説明なら
<p><img src="line.jpg" alt="x-heightとデセンダの図解"></p>
見出しなら
<h1><img src="hoge.png" alt="エレクトからエモーションへ"></h1>
素材をうｐしたいなら
<table summary="素材一覧">
<tbody>
<tr><th>アイコン</th><td><img src="maru.gif" alt="赤丸"></td>
新作のＣＧを披露したいなら
<dl>
<dt><img src="akeome.jpg" alt="あけましておめでとうございます"></dt>
<dd><p>お正月用に新作一本仕上げました、３１に日迄描いていたんですよ（爆)</p></dd>
</dl>
アイコンにしたいならcssで
ul{list-style-image:url(hoge.png);}
その他objecで画像を表示して、それをpで囲むとか。
img要素がインラインだからといってdivで囲むのは最後の手段で。
（使っていけないわけではなくて）
<p><img src="line.jpg" alt="x-heightとデセンダの図解"></p>
見出しなら
<h1><img src="hoge.png" alt="エレクトからエモーションへ"></h1>
素材をうｐしたいなら
<table summary="素材一覧">
<tbody>
<tr><th>アイコン</th><td><img src="maru.gif" alt="赤丸"></td>
新作のＣＧを披露したいなら
<dl>
<dt><img src="akeome.jpg" alt="あけましておめでとうございます"></dt>
<dd><p>お正月用に新作一本仕上げました、３１に日迄描いていたんですよ（爆)</p></dd>
</dl>
アイコンにしたいならcssで
ul{list-style-image:url(hoge.png);}
その他objecで画像を表示して、それをpで囲むとか。
img要素がインラインだからといってdivで囲むのは最後の手段で。
（使っていけないわけではなくて）
682 ：Name_Not_Found：02/05/18 12:15 ID:oo2vWtWM
DL(DT,DD)ってterm-definitionのときに使うとありますが、
そうすると、
<DL>
<DT>所在地</DT>
<DD>新宿区ZZZ1-2-3</DD>
<DT>電話</DT>
<DD>03（0000）0000 </DD>
<DT>入館料</DT>
<DD>大人 500円<br>
子ども 250円（中学生以下） </DD>
<DT>開園時間</DT>
<DD>9：00～21：00</DD>
<DT>休館日</DT>
<DD>第2水曜、年末年始</DD>
</DL>
みたいのって、間違いなんでしょうか？
そうすると、
<DL>
<DT>所在地</DT>
<DD>新宿区ZZZ1-2-3</DD>
<DT>電話</DT>
<DD>03（0000）0000 </DD>
<DT>入館料</DT>
<DD>大人 500円<br>
子ども 250円（中学生以下） </DD>
<DT>開園時間</DT>
<DD>9：00～21：00</DD>
<DT>休館日</DT>
<DD>第2水曜、年末年始</DD>
</DL>
みたいのって、間違いなんでしょうか？
683 ：Name_Not_Found：02/05/18 12:21 ID:kj4rIT4B
>>682
間違いではないでしょ。
間違いではないでしょ。
684 ：682：02/05/18 12:47 ID:oo2vWtWM
>>683
term-definitionってことは、語句説明(dt->term, dd->definiton)だから、
正確には、
<dt>電話</dt>
<dd>電話機で通話すること。また、その通話。</dd>
みたく、純粋な「語句（の定義の）説明」にしか使えないのかなと思って。
>>682 だとそうではないでしょ？
でも広義ではＯＫな気もするし。。。
term-definitionってことは、語句説明(dt->term, dd->definiton)だから、
正確には、
<dt>電話</dt>
<dd>電話機で通話すること。また、その通話。</dd>
みたく、純粋な「語句（の定義の）説明」にしか使えないのかなと思って。
>>682 だとそうではないでしょ？
でも広義ではＯＫな気もするし。。。
685 ：Name_Not_Found：02/05/18 13:04 ID:F0eOT+lL
>>684
http://www.w3.org/TR/html401/struct/lists.html#h-10.1
> Definition lists, created using the DL element,
> generally consist of a series of term/definition pairs
> (although definition lists may have other applications).
() の中。仕様書の用例も見ること。
HTML3.2 以前にはない記述だが。
http://www.w3.org/TR/html401/struct/lists.html#h-10.1
> Definition lists, created using the DL element,
> generally consist of a series of term/definition pairs
> (although definition lists may have other applications).
() の中。仕様書の用例も見ること。
HTML3.2 以前にはない記述だが。
686 ：Name_Not_Found：02/05/18 13:24 ID:UsH4ZlIA
<DD>大人 500円<br>
子ども 250円（中学生以下） </DD>
ここ<li>使ってリストにしたほうが良いかも。改行でも間違いじゃないけど。
大文字のタグ見るの久しぶりだ…xmlでは使えないから…
子ども 250円（中学生以下） </DD>
ここ<li>使ってリストにしたほうが良いかも。改行でも間違いじゃないけど。
大文字のタグ見るの久しぶりだ…xmlでは使えないから…
687 ：Name_Not_Found：02/05/18 13:36 ID:4wg0TC5N
ｽﾄﾘｸｰﾙ
688 ：Name_Not_Found：02/05/18 16:31 ID:i6slSgd8
typoなんだろうけど
xmlで使えないのではなくてxhtmlで使えない
xmlで使えないのではなくてxhtmlで使えない
689 ：Name_Not_Found：02/05/18 17:04 ID:VPL5vAC9
>>688
XMLでも使えないよっていったのはXSLTの事なんだけどね。XMLはXSLTがあってこそだと思ってたから。ごめん。紛らわしかったね。
XMLでも使えないよっていったのはXSLTの事なんだけどね。XMLはXSLTがあってこそだと思ってたから。ごめん。紛らわしかったね。
690 ：Name_Not_Found：02/05/18 20:51 ID:7RfOrI27
XMLとXSLTとXHTMLのそれぞれの役割と関連を明確にした上で、
「XMLで大文字のタグが使えない」と言う言葉の意味を説明しなさい。
>>ALL
「XMLで大文字のタグが使えない」と言う言葉の意味を説明しなさい。
>>ALL
691 ：Name_Not_Found：02/05/18 21:29 ID:oHEI/Wxw
(ﾟ⊿ﾟ)ｼﾗﾈ
692 ：Name_Not_Found：02/05/18 21:59 ID:5mLmrWjW
>>690
aとAは別の文字です。
aとAは別の文字です。
693 ：Name_Not_Found：02/05/18 22:24 ID:dZ9AypKQ
>>690
意味「XMLとXHTMLの違いがわかってないお馬鹿ですが何か？」
意味「XMLとXHTMLの違いがわかってないお馬鹿ですが何か？」
694 ：Name_Not_Found：02/05/18 23:26 ID:i+JtWrfW
サイトの説明をするとき、
<dl>
<dt>Yahoo! Japan http://www.yahoo.co.jp/</dt>
<dd>ヤフージャパンのサイト</dd>
</dl>
か、
<dl>
<dt>Yahoo! Japan</dt>
<dt>http://www.yahoo.co.jp/</dt>
<dd>ヤフージャパンのサイト</dd>
</dl>
か、ul liを使うのかどれが適当でしょうか？
<dl>
<dt>Yahoo! Japan http://www.yahoo.co.jp/</dt>
<dd>ヤフージャパンのサイト</dd>
</dl>
か、
<dl>
<dt>Yahoo! Japan</dt>
<dt>http://www.yahoo.co.jp/</dt>
<dd>ヤフージャパンのサイト</dd>
</dl>
か、ul liを使うのかどれが適当でしょうか？
695 ：Name_Not_Found：02/05/18 23:28 ID:oqhb9cNN
Yahoo をアンカーにはしたくないの？
696 ：Name_Not_Found：02/05/18 23:30 ID:5mLmrWjW
697 ：Name_Not_Found：02/05/19 00:28 ID:46J0iZOS
>>694
先手を打っておくけど、dt の中に ul を入れ子にすることはできないよ。
先手を打っておくけど、dt の中に ul を入れ子にすることはできないよ。
698 ：Name_Not_Found：02/05/19 02:10 ID:RvhleNT1
a:after {
content: attr(href);
}
content の使い方がいまいちわからんが。
まぁ、求めている答えとは違うだろうから気にしないでくれ。
content: attr(href);
}
content の使い方がいまいちわからんが。
まぁ、求めている答えとは違うだろうから気にしないでくれ。
699 ：Name_Not_Found：02/05/19 02:21 ID:qSSkVnN8
>>694
>サイトの説明をするとき、
が条件なら、どれでもOK。
URLをわざわざhtml中に描いているのはヤコブ先生の本に従って
印刷時の為にURLを記述すべきだ、ということだと思うんだけれど、
それなら、印刷用CSSに >>696 のマークアップに >>698 の指定。
…が理想なんだけど、実際に対応しているUAが余りに少ないので
htmlの中に書く事になるかなぁ…。
ちなみに自分ならURLはサイトに属する”説明”と見なしてddの中に書くが、
好みの範疇かと。
>サイトの説明をするとき、
が条件なら、どれでもOK。
URLをわざわざhtml中に描いているのはヤコブ先生の本に従って
印刷時の為にURLを記述すべきだ、ということだと思うんだけれど、
それなら、印刷用CSSに >>696 のマークアップに >>698 の指定。
…が理想なんだけど、実際に対応しているUAが余りに少ないので
htmlの中に書く事になるかなぁ…。
ちなみに自分ならURLはサイトに属する”説明”と見なしてddの中に書くが、
好みの範疇かと。
700 ：Name_Not_Found：02/05/19 03:15 ID:xZXBo4S6
印刷の時のために
URLかいとくの？
本とwebは違うんだし
そんなん気にしないほうがいいと思われ
URLかいとくの？
本とwebは違うんだし
そんなん気にしないほうがいいと思われ
701 ：Name_Not_Found：02/05/19 03:26 ID:RvhleNT1
>>700
Web は、ね。でも、Web などによって受け渡される HTML ドキュメントだよ。
印刷を考えないって？
そんなの IE のみでしか見られないマークアップと大差無いじゃない。
相手側のデフォルトスタイルに任せるのもいいけど、人に見せるもの。
見栄えだって気になると思う。
某スレの >1 をまねてみるも全然似ない罠。
Web は、ね。でも、Web などによって受け渡される HTML ドキュメントだよ。
印刷を考えないって？
そんなの IE のみでしか見られないマークアップと大差無いじゃない。
相手側のデフォルトスタイルに任せるのもいいけど、人に見せるもの。
見栄えだって気になると思う。
某スレの >1 をまねてみるも全然似ない罠。
702 ：Name_Not_Found：02/05/19 03:56 ID:46J0iZOS
>>700
印刷したときにアンカーの URI がないと何が何だか解らない文書は多いぞ。
特に「<a href="hoge.html">こちら</a>」は意味不明。
まあそれは元のマーク付けが悪いんだけど。
>>701
accesskey スレの 1 か? 漏れもああいう感じのキャラになりたい。
印刷したときにアンカーの URI がないと何が何だか解らない文書は多いぞ。
特に「<a href="hoge.html">こちら</a>」は意味不明。
まあそれは元のマーク付けが悪いんだけど。
>>701
accesskey スレの 1 か? 漏れもああいう感じのキャラになりたい。
703 ：Name_Not_Found：02/05/19 08:33 ID:TeDHonxD
もちろん、みなさんMozilla使ってるんですよね？
704 ：Name_Not_Found：02/05/19 08:52 ID:yPrqL8ct
いや、IE5.5。
Mozillaも一応入れてはあるけど。
Mozillaも一応入れてはあるけど。
705 ：Name_Not_Found：02/05/19 09:03 ID:RvhleNT1
Mozilla のタブ周りはまだまだなので DonutLight(≠IE) 使ってる。
Mozilla のコマンドラインから新しいタブが開ければ完全移行だろうな～
IE コアは 5.01SP2 。
Mozilla のコマンドラインから新しいタブが開ければ完全移行だろうな～
IE コアは 5.01SP2 。
706 ：Name_Not_Found：02/05/19 13:05 ID:qWjdcNbi
だっせ
毎回URL書くのかよ。
印刷するやつは
目が見える奴なんだから
ほかに飛びたいのならwebから飛べばいい。
さすがにURLを全部書くなんてあほなことは出来ない。もはや宗教。
毎回URL書くのかよ。
印刷するやつは
目が見える奴なんだから
ほかに飛びたいのならwebから飛べばいい。
さすがにURLを全部書くなんてあほなことは出来ない。もはや宗教。
707 ：Name_Not_Found：02/05/19 13:22 ID:h3sDFVu1
708 ：Name_Not_Found：02/05/19 13:45 ID:TeDHonxD
StrictStrictいいながら、その恩恵を受けられるMozillaもつかってねーのかよ
709 ：Name_Not_Found：02/05/19 13:47 ID:o8DnDiUd
モジラだとkanzakiたんとこのrdfが見えないんだけどなんで？
IEはよく見える
IEはよく見える
710 ：Name_Not_Found：02/05/19 13:56 ID:1JgkAGeV
711 ：Name_Not_Found：02/05/19 15:25 ID:9k5N2xDv
712 ：Name_Not_Found：02/05/19 16:10 ID:TKRBWfay
あまいに既出な感があるんですけど、小説のマークアップってどうすれば良いんでしょう？
<p class="会話文">「会話文」</p>
<p class="地の文">地の文</p>
で良いんでしょうか？
<p class="会話文">「会話文」</p>
<p class="地の文">地の文</p>
で良いんでしょうか？
713 ：Name_Not_Found：02/05/19 16:30 ID:730+u90N
「100の質問」をやってみようかと思ったんですが、質問部分と回答部分、それぞれどんな要素にすれば良いんでしょうか。
定義リストかなあ？
定義リストかなあ？
714 ：Name_Not_Found：02/05/19 16:35 ID:gCO6p26i
715 ：Name_Not_Found：02/05/19 16:36 ID:O0UkOcV5
100質を定義リストで書いてる人が多いが、
どうかと思った。
どうかと思った。
716 ：Name_Not_Found：02/05/19 16:43 ID:9k5N2xDv
717 ：Name_Not_Found：02/05/19 16:44 ID:yWoPFthD
>>709
WD版のXSLT使ってるから
WD版のXSLT使ってるから
718 ：Name_Not_Found：02/05/19 16:47 ID:ecUlGlkT
719 ：Name_Not_Found：02/05/19 18:09 ID:o8DnDiUd
XSLTってWINDOWS専用だったの？
720 ：Name_Not_Found：02/05/19 18:22 ID:/VexBKiu
>>719
何故そう思う？
何故そう思う？
721 ：Name_Not_Found：02/05/19 19:37 ID:9k5N2xDv
722 ：Name_Not_Found：02/05/19 21:05 ID:TeDHonxD
723 ：Name_Not_Found：02/05/19 21:13 ID:VFnsnXdn
724 ：Name_Not_Found：02/05/19 21:47 ID:TeDHonxD
はあ？それでもStrict原理主義？おまえは池よ
725 ：Name_Not_Found：02/05/19 21:58 ID:fmkEJkTg
>>724
なに言ってるのかわからんが、Strict主義ならIE使うだろう普通。
なに言ってるのかわからんが、Strict主義ならIE使うだろう普通。
726 ：Name_Not_Found：02/05/19 22:08 ID:fmkEJkTg
WindowsならMSXMLを使わない手はない。
MozillaはCSSなしでXMLを表示できないのが辛すぎてあぼーん。
MozillaはCSSなしでXMLを表示できないのが辛すぎてあぼーん。
727 ：茶文字 ◆xELvisFU ：02/05/19 22:09 ID:BegGKW7g
>>722
ちょい質問。
StrictなHTMLって、「ただ表示される」以外にどんなメリットがある？
そもそもStrictってのは書き手の意識の問題であって、
特定のブラウザを念頭に置いて書くものではないと思うんだ。
極端な話、(初心者が言うところの)「タグうち」じゃなくて
(Strictな)「マークアップ」をきちんとできる人なら、
ブラウザでの表示テストなんて必要ないとさえ思える。
実際にはCSSの不具合があるので必要なんだけど、
それはvalidなCSSを正しく解釈できないブラウザのバグなのであって
StrictなHTML/XHTMLの問題ではないはずだ。
だから、HTML/XHTMLの範囲に限って考えたら、我々がどんなブラウザを
常用してようが大きな問題ではないと思うんだが？
ちょい質問。
StrictなHTMLって、「ただ表示される」以外にどんなメリットがある？
そもそもStrictってのは書き手の意識の問題であって、
特定のブラウザを念頭に置いて書くものではないと思うんだ。
極端な話、(初心者が言うところの)「タグうち」じゃなくて
(Strictな)「マークアップ」をきちんとできる人なら、
ブラウザでの表示テストなんて必要ないとさえ思える。
実際にはCSSの不具合があるので必要なんだけど、
それはvalidなCSSを正しく解釈できないブラウザのバグなのであって
StrictなHTML/XHTMLの問題ではないはずだ。
だから、HTML/XHTMLの範囲に限って考えたら、我々がどんなブラウザを
常用してようが大きな問題ではないと思うんだが？
728 ：Name_Not_Found：02/05/19 22:16 ID:LcUZgvL0
ええ？XLSTってwin専用のマーキー野郎だったの？鬱
729 ：Name_Not_Found：02/05/19 22:34 ID:9k5N2xDv
>>727
結論：明日から学校なのでもう少し待ちましょう
結論：明日から学校なのでもう少し待ちましょう
730 ：Name_Not_Found：02/05/19 22:58 ID:DACkRfQu
Mozilla開発チームもXSLTの重要性には気づいている。
いずれ必ずサポートされます。いずれ。
いずれ必ずサポートされます。いずれ。
731 ：Name_Not_Found：02/05/19 23:01 ID:LcUZgvL0
WINが勝手にだしたやつなのか
Mozillaがサポートしていないのかどっちなんです？
Mozillaがサポートしていないのかどっちなんです？
732 ：Name_Not_Found：02/05/19 23:38 ID:1ihCAtPT
>>727
禿同なんだが、ほら、まぁアレだよ(ｗ
禿同なんだが、ほら、まぁアレだよ(ｗ
733 ：Name_Not_Found：02/05/19 23:59 ID:TeDHonxD
Mozillaでサイトナビゲーションバー常時オンにして
http://www.cc-net.or.jp/~piro/xul/_moz-extensions.html
でもインストールしろ
>>727
死ね
http://www.cc-net.or.jp/~piro/xul/_moz-extensions.html
でもインストールしろ
>>727
死ね
734 ：Name_Not_Found：02/05/20 00:36 ID:ByfI0Y+Q
735 ：Name_Not_Found：02/05/20 00:40 ID:4G4jw/R3
微妙に荒れてるstrictスレ。なんか新鮮。
736 ：Name_Not_Found：02/05/20 00:44 ID:Q0CCzZdh
ごくごく一例だが、
http://www.page.sannet.ne.jp/hirasho/diary/diary0205.html#18p4
読んで意味が分からないとかほざける>>733のような方は
http://pc.2ch.net/test/read.cgi/hp/1020991711/
こちらにいることが適切です
http://www.page.sannet.ne.jp/hirasho/diary/diary0205.html#18p4
読んで意味が分からないとかほざける>>733のような方は
http://pc.2ch.net/test/read.cgi/hp/1020991711/
こちらにいることが適切です
737 ：Name_Not_Found：02/05/20 07:57 ID:LPB0i8Ax
>>727
strictのメリットっつったら
・ユーザが未知のスタイルシートつかってても劇的にぶっ壊れる事は無い。
・文書の永続性。
かな。
「文書の永続性」はブラウザ用、見栄え重視不思議マークアップの場合、
将来それが意図どおりに表示される保証が何処にも無い、っつう意味ね。
strictのメリットっつったら
・ユーザが未知のスタイルシートつかってても劇的にぶっ壊れる事は無い。
・文書の永続性。
かな。
「文書の永続性」はブラウザ用、見栄え重視不思議マークアップの場合、
将来それが意図どおりに表示される保証が何処にも無い、っつう意味ね。
738 ：茶文字 ◆xELvisFU ：02/05/20 08:16 ID:FWklb/KS
>>737
少なくともその二点に限っていえば、Mozilla でなくても問題にはならないですな。
Mozillaの優位性は認めるにしても、Stricter がそれ以外のUAを使うべきではないという
理由には弱すぎ。
少なくともその二点に限っていえば、Mozilla でなくても問題にはならないですな。
Mozillaの優位性は認めるにしても、Stricter がそれ以外のUAを使うべきではないという
理由には弱すぎ。
739 ：Name_Not_Found：02/05/20 09:05 ID:OcjOiKXt
740 ：Name_Not_Found：02/05/20 09:27 ID:2vFJHss8
>>731
何言ってるのかイマイチわからないけど
WINってIEのこと？
W3C勧告のXSLTならIE6(MSXML3以降）,Mozillaで使える。
IE5,IE6で使えるのはMSの独自XSL（XSLのドラフトのXSLTに相当する部分）。
何言ってるのかイマイチわからないけど
WINってIEのこと？
W3C勧告のXSLTならIE6(MSXML3以降）,Mozillaで使える。
IE5,IE6で使えるのはMSの独自XSL（XSLのドラフトのXSLTに相当する部分）。
741 ：Name_Not_Found：02/05/20 09:44 ID:KwjjW3oT
>>727
Strict(というか論理マークアップ)なHTMLは、再利用性が高い。これに尽きる。
単純に perl や awk でデータ抽出すること考えたって、
物理マークアップのみの文書は無茶苦茶扱いにくい。
# そういう小さなスクリプトの一つ一つだって
# 表示はしなくても HTML を解析しているわけで、立派な UA と言える。
Strict(というか論理マークアップ)なHTMLは、再利用性が高い。これに尽きる。
単純に perl や awk でデータ抽出すること考えたって、
物理マークアップのみの文書は無茶苦茶扱いにくい。
# そういう小さなスクリプトの一つ一つだって
# 表示はしなくても HTML を解析しているわけで、立派な UA と言える。
742 ：Name_Not_Found：02/05/20 12:57 ID:GYA07v61
まあ理念は理念として、W3C以外にISOとかあるんだし、
もしかしてoperaはaddress要素がdivに入ってないと無視
するとかありえるとなると、いちおうチェックは必要。
もしかしてoperaはaddress要素がdivに入ってないと無視
するとかありえるとなると、いちおうチェックは必要。
743 ：Name_Not_Found：02/05/20 13:52 ID:I9LYuTJU
ageちゃえ（藁
744 ：Name_Not_Found：02/05/20 15:26 ID:BfK0hfLb
そういえば、MSXML4も既にありますな。
745 ：Name_Not_Found：02/05/20 16:56 ID:H5fQFEom
>それ以外のUAを使うべきではないという
そんなこと誰か言ってましたっけ？
そんなこと誰か言ってましたっけ？
746 ：Name_Not_Found：02/05/20 19:02 ID:YdeNrJoH
Strictな方専用のWEBサーバを作ろうと思うのですが、機能的にはどのようなものが欲しいのでしょうか？
747 ：Name_Not_Found：02/05/20 19:11 ID:OcjOiKXt
>>740
IE6はMSXML3がデフォルトだよね。
IE6はMSXML3がデフォルトだよね。
748 ：Name_Not_Found：02/05/20 20:20 ID:EYyL2gNj
749 ：Name_Not_Found：02/05/20 20:36 ID:Yqy2wYeq
>>748
最新っちーのは 2.x のことかぇ？
最新っちーのは 2.x のことかぇ？
750 ：Name_Not_Found：02/05/20 20:49 ID:C8b+HyKP
>>748
URLに~が入らないってことは、サブドメインでってこと？
URLに~が入らないってことは、サブドメインでってこと？
751 ：Name_Not_Found：02/05/20 22:05 ID:GzYTarsE
広告が入らない、もしくは、広告がstrict。
あと、その広告は勝手に別窓を開かないとか、そんな感じ。
.htaccessは欲しいところだけど、ssi辺りは俺は要らないかな、という感じ。
単に"strictな人用サーバ"であるならば、だけど (当然ユーザとしてはありありの方がうれしい)。
あと、その広告は勝手に別窓を開かないとか、そんな感じ。
.htaccessは欲しいところだけど、ssi辺りは俺は要らないかな、という感じ。
単に"strictな人用サーバ"であるならば、だけど (当然ユーザとしてはありありの方がうれしい)。
752 ：Name_Not_Found：02/05/20 22:14 ID:Ff7Tqt1+
>>746
XMLParser, XSLT必須
XMLParser, XSLT必須
753 ：Name_Not_Found：02/05/20 22:17 ID:4YeDZvPP
無料なら公告が先頭に入るのは当然だけど、
ある程度カスタマイズ出来たり公告が選べたりすると嬉しい。
ある程度カスタマイズ出来たり公告が選べたりすると嬉しい。
754 ：Name_Not_Found：02/05/20 22:21 ID:Ff7Tqt1+
>>753
公告＝公共団体による告知
公告＝公共団体による告知
755 ：茶文字 ◆xELvisFU ：02/05/20 22:22 ID:0QGFTY/x
>>741
確かに、XHTMLで終了タグの省略が禁止されたのは、プログラムによる解析を
容易にするという意図もあるわけだし。
>>745
あ、私の脳内の>>708がそんなことを言っていたような気がしましたが、
幻聴だったようですｗ
>>751
広告がStrict(･∀･)ｲｲ!
確かに、XHTMLで終了タグの省略が禁止されたのは、プログラムによる解析を
容易にするという意図もあるわけだし。
>>745
あ、私の脳内の>>708がそんなことを言っていたような気がしましたが、
幻聴だったようですｗ
>>751
広告がStrict(･∀･)ｲｲ!
756 ：Name_Not_Found：02/05/20 22:22 ID:Ff7Tqt1+
つーか、広告とWebサーバは無関係だと思うが。
757 ：Name_Not_Found：02/05/20 22:24 ID:Ff7Tqt1+
758 ：Name_Not_Found：02/05/20 22:31 ID:KwjjW3oT
759 ：Name_Not_Found：02/05/20 23:19 ID:H5fQFEom
ところで有料にするの？
760 ：Name_Not_Found：02/05/21 00:32 ID:rQNQ/1Tn
>>751
>>755
たしかに広告がstrictなのはイイけど、それだと、CSSを使って広告を表示
させなくする（display : noneとか）不届きなユーザーが増えそうな気も
します。
まあ、CSS使えない（使わない）環境では丸見えなわけだし、真のストリクター
（って何）ならそんなことはしないでしょうが、商売としてはどうなのかと。
>>755
たしかに広告がstrictなのはイイけど、それだと、CSSを使って広告を表示
させなくする（display : noneとか）不届きなユーザーが増えそうな気も
します。
まあ、CSS使えない（使わない）環境では丸見えなわけだし、真のストリクター
（って何）ならそんなことはしないでしょうが、商売としてはどうなのかと。
761 ：Name_Not_Found：02/05/21 02:49 ID:unPsoPWW
>>760
広告の挿入ができるなら、head要素の一番最後に
<style type="text/css">#hoge{display:block}</style>
も挿入できるかと。
あとまぁ、規約として広告を非表示にしちゃいかん、と言う事に
しておけばとりあえずいいかと（違反したら、削除）
まぁ、その気になったら何とかなりますよ、程度に。
かなりスレ違いな感じ。sage
広告の挿入ができるなら、head要素の一番最後に
<style type="text/css">#hoge{display:block}</style>
も挿入できるかと。
あとまぁ、規約として広告を非表示にしちゃいかん、と言う事に
しておけばとりあえずいいかと（違反したら、削除）
まぁ、その気になったら何とかなりますよ、程度に。
かなりスレ違いな感じ。sage
762 ：茶文字 ◆xELvisFU ：02/05/21 03:15 ID:ZT6YwlzN
>761
ついでに important も書けちゃいますな。
こういう配慮をしてくれる鯖だったらｶﾅｰﾘ応援したくなるかも。
広告ってたいがい center だったり table だったりするし。
# と、とってつけたようにスレ違いを修正（したふり）をしてみる。
ついでに important も書けちゃいますな。
こういう配慮をしてくれる鯖だったらｶﾅｰﾘ応援したくなるかも。
広告ってたいがい center だったり table だったりするし。
# と、とってつけたようにスレ違いを修正（したふり）をしてみる。
763 ：Name_Not_Found：02/05/21 05:10 ID:hHc0ySn7
いえ、実は今、無料鯖屋なんですけど、方向転換しようかと…。
広告は入れない予定なんですけど、Strictな広告ってのも面白いですね。
ただ、スポンサーがつくかどうかは疑問ですが（笑）
とりあえず、無料です。
>>752
>XMLParser, XSLT必須
ここら辺がいまいち理解できていないのですが…(;´Д`)
広告は入れない予定なんですけど、Strictな広告ってのも面白いですね。
ただ、スポンサーがつくかどうかは疑問ですが（笑）
とりあえず、無料です。
>>752
>XMLParser, XSLT必須
ここら辺がいまいち理解できていないのですが…(;´Д`)
765 ：Name_Not_Found：02/05/21 07:50 ID:FlTz51m/
766 ：Name_Not_Found：02/05/21 13:47 ID:FbYZbo/f
<a href="hoge">ほげ</a> だけの広告をソースの任意の場所にｿｳﾆｭｳさせる、
ってすると広告を意識したスタイル作成が出来るから楽しいかも。
ソースに <!-- Strict_Ad_Here --> みたいに書くとそこを入れ替えるとか。
こうする利点はページのイメージに沿わせられるからユーザサイドで消したくなり難いこと。
欠点は如何せん目立たないことかな。
ってすると広告を意識したスタイル作成が出来るから楽しいかも。
ソースに <!-- Strict_Ad_Here --> みたいに書くとそこを入れ替えるとか。
こうする利点はページのイメージに沿わせられるからユーザサイドで消したくなり難いこと。
欠点は如何せん目立たないことかな。
とりあえず、Strictな人だけをユーザ対象としているので少人数鯖になると思うんです。
だから多少の無茶は出来ると思うんですが…。なにせ、Strictを知ってからまだあんまりたってないので
Strictの知識が…（笑
とりあえず、頑張ってみます。
だから多少の無茶は出来ると思うんですが…。なにせ、Strictを知ってからまだあんまりたってないので
Strictの知識が…（笑
とりあえず、頑張ってみます。
768 ：Name_Not_Found：02/05/21 16:15 ID:QLNehPKF
なんとなく746の運営している鯖が特定できたんですがネタばらし可ですか？（ｗ
769 ：Name_Not_Found：02/05/21 19:10 ID:hhbXtrwe
あっていたら神だけど
間違っていたら誤爆房だな・・
間違っていたら誤爆房だな・・
770 ：Name_Not_Found：02/05/21 20:30 ID:vSNUCeMA
>>746
ここだとstrictなHTML関連の情報以外基本的にスレ違いになっちゃうから、
XMLやアパッチに話が及ぶようだったら、いっその事新スレ立てちゃえば？
>>769
いや、今回のはなんとなく解るよ、といって、>>768と俺の
思ってるのと、正解とが同じ保証なんて全然無いんだけどな。
ここだとstrictなHTML関連の情報以外基本的にスレ違いになっちゃうから、
XMLやアパッチに話が及ぶようだったら、いっその事新スレ立てちゃえば？
>>769
いや、今回のはなんとなく解るよ、といって、>>768と俺の
思ってるのと、正解とが同じ保証なんて全然無いんだけどな。
771 ：Name_Not_Found：02/05/21 20:34 ID:O3H29PUy
CSS関係者が関係しますか?
773 ：Name_Not_Found：02/05/21 23:41 ID:gBo5cHQH
あれ、もしや…。
現ユーザかもしれないんですけどその辺はどうなるんでしょう？(;´Д`)
って思い切りスレ違いsage
あと、http://pc.2ch.net/test/read.cgi/hp/1006224399/l50で話題になってたり。accesskeyスレです。次スレからは関連スレにしてもいいのでわ？
現ユーザかもしれないんですけどその辺はどうなるんでしょう？(;´Д`)
って思い切りスレ違いsage
あと、http://pc.2ch.net/test/read.cgi/hp/1006224399/l50で話題になってたり。accesskeyスレです。次スレからは関連スレにしてもいいのでわ？
774 ：Name_Not_Found：02/05/22 22:16 ID:weXnQp8M
彼はStrictである事にはこだわってないようだが。
スポンサーの方はStrictだろうが何だろうが構いはしないでしょ。
バナー画像とリンク先さえきちっと表示できれば問題無し。
こちらからalt用のテキストを要求するぐらいかな。
スポンサーの方はStrictだろうが何だろうが構いはしないでしょ。
バナー画像とリンク先さえきちっと表示できれば問題無し。
こちらからalt用のテキストを要求するぐらいかな。
775 ：Name_Not_Found：02/05/22 22:56 ID:e/4Rg1rg
英語を<span class="english"></span>で囲む？
それをやるなら<span xml:lang="ja"></span>でしょう。
それをやるなら<span xml:lang="ja"></span>でしょう。
訂正 : ja → en
777 ：Name_Not_Found：02/05/23 00:00 ID:OXTZxfW5
778 ：Name_Not_Found：02/05/23 00:20 ID:5Y6yrvmj
779 ：Name_Not_Found：02/05/23 00:30 ID:uwtFAYvx
>>778
誤爆じゃなくて「ﾄﾝﾃﾞﾓ系ﾊｹｰｿ」の報告ではないかと。
しかし、h1-h6 の解説とか凄いなぁ、なんつっても
>Copyright 2002
ってのが一番凄い。5年くらい前の文書の生き残りってんなら
まだ苦笑いしながら眺めていられるんだが。
誤爆じゃなくて「ﾄﾝﾃﾞﾓ系ﾊｹｰｿ」の報告ではないかと。
しかし、h1-h6 の解説とか凄いなぁ、なんつっても
>Copyright 2002
ってのが一番凄い。5年くらい前の文書の生き残りってんなら
まだ苦笑いしながら眺めていられるんだが。
780 ：Name_Not_Found：02/05/23 00:41 ID:5Y6yrvmj
781 ：Name_Not_Found：02/05/23 01:21 ID:5Y6yrvmj
あ、ちゆ板の転載か…。
http://tiyu.to/cgi-bin/bbs/bbs.cgi
http://tiyu.to/cgi-bin/bbs/bbs.cgi
782 ：Name_Not_Found：02/05/23 01:41 ID:wNIFVheL
783 ：Name_Not_Found：02/05/23 03:49 ID:z+PBOXFs
784 ：Name_Not_Found：02/05/23 04:05 ID:z+PBOXFs
sagarisugi
785 ：Name_Not_Found：02/05/23 04:27 ID:IKDr//Je
Mozilla入れてるからNetscapeの方は入れないなー
786 ：Name_Not_Found：02/05/23 13:24 ID:HY4cYE6b
787 ： ：02/05/23 13:30 ID:jOTG6+Lv
>786
「罰ゲームに用いられたとされる鉄の棒」
もし写真にキャプションがついてるなら「（鉄の棒の写真）」
何か悩むところでも？
「罰ゲームに用いられたとされる鉄の棒」
もし写真にキャプションがついてるなら「（鉄の棒の写真）」
何か悩むところでも？
788 ：Name_Not_Found：02/05/23 13:51 ID:HY4cYE6b
尻に鉄棒で重症
同級生ら書類送検
の文字はどうしましょ？
同級生ら書類送検
の文字はどうしましょ？
789 ：Name_Not_Found：02/05/23 14:04 ID:5uLibAL6
790 ：Name_Not_Found：02/05/23 15:01 ID:gHKyzBO3
>>786
関係ないが、それ地元なんだ…。
関係ないが、それ地元なんだ…。
791 ：Name_Not_Found：02/05/23 19:12 ID:LwLq8ucn
N7PR1とか出てるんだね。Netscapeって、いよいよ頭おかしいね。
792 ：Name_Not_Found：02/05/23 21:04 ID:JvJh43s6
元々５が無いようなヴァージョン管理だからなぁ＞ネスケ。
まぁ、どう名乗ろうとかってなんだけど、こんな事やってると
ヴァージョンの意味がなくなって、（今ネスケが７と名乗ることによって
得られると勝手に思い込んでいる）新ヴァージョンと言う競合製品に
対する優位性そのものを失う事が解らないんだろうな。
結局ネスケは勝手にHTMLに独自要素を搭載していってそれが競合製品に
対する優位性に繋がると思い込んでいた頃と殆ど変わってないって事か。
スレ違いsage。
まぁ、どう名乗ろうとかってなんだけど、こんな事やってると
ヴァージョンの意味がなくなって、（今ネスケが７と名乗ることによって
得られると勝手に思い込んでいる）新ヴァージョンと言う競合製品に
対する優位性そのものを失う事が解らないんだろうな。
結局ネスケは勝手にHTMLに独自要素を搭載していってそれが競合製品に
対する優位性に繋がると思い込んでいた頃と殆ど変わってないって事か。
スレ違いsage。
793 ：Name_Not_Found：02/05/23 21:39 ID:HTdHEitH
>>792
まぁ、重いわバグだらけだわで6のイメージが最悪だからな。
まぁ、重いわバグだらけだわで6のイメージが最悪だからな。
794 ：Name_Not_Found：02/05/24 05:41 ID:HcQTWm6l
>>794
そりゃ失礼。HTML3.0みたいなもんか…違うか? …どっちでもいいや(謎)
そりゃ失礼。HTML3.0みたいなもんか…違うか? …どっちでもいいや(謎)
796 ：Name_Not_Found：02/05/24 12:45 ID:RGqBonik
6もねえ6.0なんてアドレスバーに
URLをコピペできなかったから
手打ちだモンな
あほすぎた。
URLをコピペできなかったから
手打ちだモンな
あほすぎた。
797 ：Name_Not_Found：02/05/24 17:55 ID:fnGnfJx7
1.0RC3出たね。N7正式版は1.0正式版の2ヶ月ぐらいあとかもね。
798 ：Name_Not_Found：02/05/24 20:43 ID:mDeYbJGm
799 ：Name_Not_Found：02/05/24 22:18 ID:bdNkmvKZ
800 ：Name_Not_Found：02/05/25 08:04 ID:1qANbZdj
MozillaつかえよMozilla
801 ：Name_Not_Found：02/05/25 15:54 ID:fPGAAPGu
ここんところ、Strictな話題がない罠
802 ：Name_Not_Found：02/05/25 17:13 ID:V9x4U8HD
では私めがstrictな話題を一つ。
アクセスシビリティに画像と文字列があって、それにアンカー
がついている場合、
<a href="http://www.2ch.net/"><img src="tubo.jpg" alt=" ">2ch</a>
という風にalt=" " に半角スペースをいれろと書いてあったけどなんで？
Another-lintでは空白いれるなって叱られちゃった。
アクセスシビリティに画像と文字列があって、それにアンカー
がついている場合、
<a href="http://www.2ch.net/"><img src="tubo.jpg" alt=" ">2ch</a>
という風にalt=" " に半角スペースをいれろと書いてあったけどなんで？
Another-lintでは空白いれるなって叱られちゃった。
803 ：Name_Not_Found：02/05/25 17:39 ID:MgPytPTH
そんな話は聞いた事が御座いませんが。
この場合は alt="" で良いと思うのだが。
この場合は alt="" で良いと思うのだが。
804 ：Name_Not_Found：02/05/25 17:53 ID:5+JDgSJf
和ジラとか言ってる人がいますが、どうよ。
805 ：Name_Not_Found：02/05/25 18:10 ID:j6+HzDkl
>>802
>>803 に同意。
画像非表示の時に <a><img/>1ch</a><a><img/>2ch</a> が
1ch2ch と表示されないように、という意味かも知れないが、
それだったら </a> と <a> の間に空白を入れるべき。
>>803 に同意。
画像非表示の時に <a><img/>1ch</a><a><img/>2ch</a> が
1ch2ch と表示されないように、という意味かも知れないが、
それだったら </a> と <a> の間に空白を入れるべき。
806 ：Name_Not_Found：02/05/25 18:11 ID:8Ut9FGmZ
807 ：Name_Not_Found：02/05/25 18:28 ID:V9x4U8HD
808 ：Name_Not_Found：02/05/25 18:40 ID:sgp1tvVk
alt="画像が表示出来ない奴は帰れ" エラーが出なくなるよー。
809 ：Name_Not_Found：02/05/25 18:46 ID:V9x4U8HD
>>808
そうゆうメッセージはtitle属性にてどうぞ
そうゆうメッセージはtitle属性にてどうぞ
810 ：Name_Not_Found：02/05/25 19:50 ID:j6+HzDkl
>>809
alt であってると思われ。
alt であってると思われ。
811 ：Name_Not_Found：02/05/25 19:52 ID:lLd5glNb
>>807
6.1.1 リンクしている画像につけるテキスト
該当するチェックポイント：
1.1 テキスト以外の要素には、必ず同等の役割を果たすテキストをつける（alt属性やlongdesc属性、または要素の内容として）。
テキスト以外の要素とは、次のようなものを指す。
画像、グラフィカルな表現をしたもの（記号も含む）、イメージマップの領域、GIFアニメなどのアニメーション、
アプレットなどのプログラムによるオブジェクト、ASCIIアート、フレーム、スクリプト、リスト項目の前につける画像、
スペーサー、画像によるボタン、音（ユーザーが制御可能であるかどうかにかかわらず）、音声ファイル、映像の音声、映像。 [優先度1]
リンクの内容として画像を使う場合は、その画像に対して同等の役割を果たすテキストを指定してください。
【例】
<A href="routes.html">
<IMG src="topo.html"
alt="ボールダー・クライミング・ジムへの行き方">
</A>
【例終了】
もしくは、リンクとしてテキストもつけている場合は、IMG要素のalt属性の値としてスペースを入れてください。このテキストは画像の横に表示されることに注意してください。
【例】
<A href="routes.html">
<IMG src="topo.html" alt=" ">
ボールダー・クライミング・ジムへの行き方
</A>
【例終了】
注意：一部こちらで改行を入れました。
6.1.1 リンクしている画像につけるテキスト
該当するチェックポイント：
1.1 テキスト以外の要素には、必ず同等の役割を果たすテキストをつける（alt属性やlongdesc属性、または要素の内容として）。
テキスト以外の要素とは、次のようなものを指す。
画像、グラフィカルな表現をしたもの（記号も含む）、イメージマップの領域、GIFアニメなどのアニメーション、
アプレットなどのプログラムによるオブジェクト、ASCIIアート、フレーム、スクリプト、リスト項目の前につける画像、
スペーサー、画像によるボタン、音（ユーザーが制御可能であるかどうかにかかわらず）、音声ファイル、映像の音声、映像。 [優先度1]
リンクの内容として画像を使う場合は、その画像に対して同等の役割を果たすテキストを指定してください。
【例】
<A href="routes.html">
<IMG src="topo.html"
alt="ボールダー・クライミング・ジムへの行き方">
</A>
【例終了】
もしくは、リンクとしてテキストもつけている場合は、IMG要素のalt属性の値としてスペースを入れてください。このテキストは画像の横に表示されることに注意してください。
【例】
<A href="routes.html">
<IMG src="topo.html" alt=" ">
ボールダー・クライミング・ジムへの行き方
</A>
【例終了】
注意：一部こちらで改行を入れました。
812 ：Name_Not_Found：02/05/25 19:59 ID:V9x4U8HD
さてはみなあんまり
アクセスシビリティを勉強していないな。
lintでぱっと採点ってわけにはいかないから
みなつい手を抜きやすいのかもしれん。
アクセスシビリティを勉強していないな。
lintでぱっと採点ってわけにはいかないから
みなつい手を抜きやすいのかもしれん。
813 ：Name_Not_Found：02/05/25 20:03 ID:V9x4U8HD
<a href="hoge"><img src="hoge" alt="hoge">hoge</a>
てのは冗長だからやめておけって聞いたことはある
音声ブラウザが2度同じ事をいうからね。画像とテキストが別の意味を
もたない限りaltは空にすべきではある。
でもなんで空白を入れるのかは知らない
教えて>>えらい人
てのは冗長だからやめておけって聞いたことはある
音声ブラウザが2度同じ事をいうからね。画像とテキストが別の意味を
もたない限りaltは空にすべきではある。
でもなんで空白を入れるのかは知らない
教えて>>えらい人
814 ：Name_Not_Found：02/05/25 20:17 ID:mpsYxtaT
815 ：Name_Not_Found：02/05/25 20:42 ID:pa2PqCkF
同一ページに
aaa#abc
bbb#abcと
#以下を同じ名前にしては行けないのですか？
ファイル名が違うから良いと思ったのですが、
駄目みたいなんですが。
aaa#abc
bbb#abcと
#以下を同じ名前にしては行けないのですか？
ファイル名が違うから良いと思ったのですが、
駄目みたいなんですが。
816 ：Name_Not_Found：02/05/25 20:47 ID:V9x4U8HD
同一ページ＝ファイル名が同じでは？
817 ：Name_Not_Found：02/05/25 21:05 ID:q1klGZ3y
818 ：815：02/05/25 21:17 ID:pa2PqCkF
間違いました。
index.htmlに
./aaa.html#abcと
../bbb.html#abcを
つけましたが、違うファイル名なのに
駄目みたいなんです。
なぜでしょうか？
index.htmlに
./aaa.html#abcと
../bbb.html#abcを
つけましたが、違うファイル名なのに
駄目みたいなんです。
なぜでしょうか？
819 ：Name_Not_Found：02/05/25 21:46 ID:KYP/yMcm
同一ファイル内に同一IDは駄目です。
index.html内に
./aaa.html#abc
./bbb.html#def
はOK。
index.html内に
./aaa.html#abc
text.html内に
./aaa.html#def
でもOK。
index.html内に
./aaa.html#abc
./bbb.html#def
はOK。
index.html内に
./aaa.html#abc
text.html内に
./aaa.html#def
でもOK。
821 ：Name_Not_Found：02/05/25 22:22 ID:DuaQi0Uk
xreaの垢とってみたが、広告タグをStrictにすることはできないだろうか
822 ：Name_Not_Found：02/05/25 22:29 ID:KYP/yMcm
xreaに相談してみれば？
もしくは、DTDを変更…
もしくは、DTDを変更…
>>821
FAQ読め。
FAQ読め。
825 ：Name_Not_Found：02/05/25 22:38 ID:lqRlIbid
>>821
それらしくすることはできるよ。
それらしくすることはできるよ。
826 ：Name_Not_Found：02/05/26 01:14 ID:lOTC/oA5
827 ：Name_Not_Found：02/05/26 09:24 ID:xubI/e+N
828 ：Name_Not_Found：02/05/26 09:37 ID:0xd/LF01
同一ファイル内に同一IDを割り振っちゃlintで怒られるって言いたかったんだろ。
829 ：Name_Not_Found：02/05/26 12:09 ID:ZviG5c3C
830 ：Name_Not_Found：02/05/26 12:48 ID:lOTC/oA5
同一ﾄﾞｷｭｿﾒｿﾄ内で
<a href="hoge.html#aaa">ほげのぺーじ</a>
-
-
-
-
<a href ="hage.html#aaa">はげのぺーじ</a>
でひっかかったつーことかな。
<a href="hoge.html#aaa">ほげのぺーじ</a>
-
-
-
-
<a href ="hage.html#aaa">はげのぺーじ</a>
でひっかかったつーことかな。
831 ：Name_Not_Found：02/05/26 14:15 ID:xubI/e+N
しかし830のではひっかからないっぽいんですけど。
lintではなく、アクセシビリティかなんかでよろしくない
こととされておるのであろうか？しかしそれはない。なぜなら
bookmark.htmlにて
<li><a href="http://www.w3.org/TR/hoge#list-1-6">list構造</a></li>
<li><a href="http://www.asahi.net/%7ehoge/hoge#list-1-6">list構造(邦訳)</a></li>
という場合も考えられる。これがダメなんてことは無い。
ただ超Strictな考えで、同一サイト内で同じIDを使うなって
教えがもしかしたら815のいうとおりにあるのであろうか？((( ；ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙ
lintではなく、アクセシビリティかなんかでよろしくない
こととされておるのであろうか？しかしそれはない。なぜなら
bookmark.htmlにて
<li><a href="http://www.w3.org/TR/hoge#list-1-6">list構造</a></li>
<li><a href="http://www.asahi.net/%7ehoge/hoge#list-1-6">list構造(邦訳)</a></li>
という場合も考えられる。これがダメなんてことは無い。
ただ超Strictな考えで、同一サイト内で同じIDを使うなって
教えがもしかしたら815のいうとおりにあるのであろうか？((( ；ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙ
832 ：Name_Not_Found：02/05/26 15:01 ID:KbeG2Zek
結局は819に全責任があるわけだ。
ヘボ解説者は初心者より厄介だね。
ヘボ解説者は初心者より厄介だね。
833 ：CSS質問スレ389：02/05/26 16:04 ID:yyXmFBRI
<div class="title">
<h1>サイト名</h1>
</div>
div.title{
background : url(hoge.png) no-repeat;
height : ☆px;
}
h1{
display : none;
}
こういう記述はstrict的にはNG？
<h1>サイト名</h1>
</div>
div.title{
background : url(hoge.png) no-repeat;
height : ☆px;
}
h1{
display : none;
}
こういう記述はstrict的にはNG？
834 ：CSS質問スレ389：02/05/26 16:07 ID:yyXmFBRI
あ、補足。
文法的には大丈夫なはずだと思うんだけど、聞きたいのは考え方的にです。
いや、あるスタイルを前提としたマークアップはいかんというのは承知しておりまふ。
文法的には大丈夫なはずだと思うんだけど、聞きたいのは考え方的にです。
いや、あるスタイルを前提としたマークアップはいかんというのは承知しておりまふ。
835 ：Name_Not_Found：02/05/26 16:10 ID:V1oQs63l
<h1><img src="hoge.png" alt="サイト名"></h1>
じゃ駄目な理由は？
じゃ駄目な理由は？
836 ：CSS質問スレ389：02/05/26 16:23 ID:yyXmFBRI
837 ：Name_Not_Found：02/05/26 16:37 ID:FoPmI75q
切り替えスクリプトを使うって事はJSなりcgiなりを使うんだろうから，
それで直接h1を書き換えちゃえば？
h1の中身が「デザイン」ならばCSSで扱うのが適当なんだろうけど，
h1の中身はデザインとは離れた文章の一部だと思うと
中身そのものを書き換えるのがstrict的なんじゃないかな，と思う．
それで直接h1を書き換えちゃえば？
h1の中身が「デザイン」ならばCSSで扱うのが適当なんだろうけど，
h1の中身はデザインとは離れた文章の一部だと思うと
中身そのものを書き換えるのがstrict的なんじゃないかな，と思う．
838 ：Name_Not_Found：02/05/26 16:50 ID:ZviG5c3C
839 ：CSS質問スレ389：02/05/26 16:57 ID:yyXmFBRI
>>837
えぇっと多分デザインかと思われ。hoge.pngはサイトのタイトル画像なの。
文章じゃないのね。
だからこの場合はcssで操作する方が合ってるはず。
ちなみにcgiは不可。jsも書き換えちゃうなんて高等記述は皆無(ｗ
結局何が言いたいのかというと、<div>で囲むというマークアップは助長なのか？
という事。厳密ストリクター的にはあまりいただけないのかなぁと。
でもあまり厳密に考えすぎるとデザインの幅が狭まるし。
でもさ、<div>でマークアップするのってデザイン性を高めたいが故にやってる人
って多いじゃない？病とまではいかないまでも。どうなの？それって？
どこまでが許容されるべき？線引きがないからすげー悩むのよ。
そこでこのスレの住人的にはどうなのかなぁと。
何か話しがズレズレだけれども(ｗ
えぇっと多分デザインかと思われ。hoge.pngはサイトのタイトル画像なの。
文章じゃないのね。
だからこの場合はcssで操作する方が合ってるはず。
ちなみにcgiは不可。jsも書き換えちゃうなんて高等記述は皆無(ｗ
結局何が言いたいのかというと、<div>で囲むというマークアップは助長なのか？
という事。厳密ストリクター的にはあまりいただけないのかなぁと。
でもあまり厳密に考えすぎるとデザインの幅が狭まるし。
でもさ、<div>でマークアップするのってデザイン性を高めたいが故にやってる人
って多いじゃない？病とまではいかないまでも。どうなの？それって？
どこまでが許容されるべき？線引きがないからすげー悩むのよ。
そこでこのスレの住人的にはどうなのかなぁと。
何か話しがズレズレだけれども(ｗ
840 ：Name_Not_Found：02/05/26 17:38 ID:nnxRRx/2
>>839
>タイトル画像なの。文章じゃないのね。
>だからこの場合はcssで操作する方が合ってるはず。
?
念のために言っておくが、HTML=文章、CSS=画像なんてことは無いぞ？
文章でもそれが装飾であれば CSS のコンテンツプロパティを使うべきだし、
画像でも、文書構造に含まれるようなものならばHTMLに書かないと寧ろ駄目。
単純にそれだけの話なんであって「結果としてそれがデザイン性を高めるかどうか」
ってのはstrictとは関係の無い話。
あと、
>以前、っつーか今もそうやってるんだけど、切り替えスクリプトで画像を入れ替えたい
>のね。そうなるとCSSで操作しなくちゃいかんのよ。
これって、全然strictとは関係の無い論拠だよな(やる「手段」がない、
と言っている訳でstrictな思想とは関係ない訳だろ)。
>どこまでが許容されるべき？線引きがないからすげー悩むのよ。
strict(厳格)に”許容”はない。正しいか、正しくないか、が仕様に沿って
判断されるだけ。あとはユーザーサイドがUAの現状に合わせて妥協するか
どうか、と言う話。
>タイトル画像なの。文章じゃないのね。
>だからこの場合はcssで操作する方が合ってるはず。
?
念のために言っておくが、HTML=文章、CSS=画像なんてことは無いぞ？
文章でもそれが装飾であれば CSS のコンテンツプロパティを使うべきだし、
画像でも、文書構造に含まれるようなものならばHTMLに書かないと寧ろ駄目。
単純にそれだけの話なんであって「結果としてそれがデザイン性を高めるかどうか」
ってのはstrictとは関係の無い話。
あと、
>以前、っつーか今もそうやってるんだけど、切り替えスクリプトで画像を入れ替えたい
>のね。そうなるとCSSで操作しなくちゃいかんのよ。
これって、全然strictとは関係の無い論拠だよな(やる「手段」がない、
と言っている訳でstrictな思想とは関係ない訳だろ)。
>どこまでが許容されるべき？線引きがないからすげー悩むのよ。
strict(厳格)に”許容”はない。正しいか、正しくないか、が仕様に沿って
判断されるだけ。あとはユーザーサイドがUAの現状に合わせて妥協するか
どうか、と言う話。
841 ：Name_Not_Found：02/05/26 17:48 ID:h6DzhVxi
で
俺もalt=" "
の理由を知りたいのですが
誰も知らないのかな？
まあお上が言うことは素直に守っていればいいか。
おっと君らのお上はW3Cでなく某lintサービスだったね。
俺もalt=" "
の理由を知りたいのですが
誰も知らないのかな？
まあお上が言うことは素直に守っていればいいか。
おっと君らのお上はW3Cでなく某lintサービスだったね。
842 ：Name_Not_Found：02/05/26 17:57 ID:Bn86Rao6
>>841
ttp://www.google.co.jp/search?hl=ja&q=space+alt+attribute+value+IMG+element+site%3Alists.w3.org&lr=
暇があったら↑これ一通り見てみて。
今ちょっと体調不良なんで、自分で見る気力がない。
ちなみに W3C の Ian Jacobs が投げている
ttp://lists.w3.org/Archives/Public/wai-wcag-editor/2001OctDec/0008.html
がそのものズバリなのだが、特にレスは付いていない模様。
ttp://www.google.co.jp/search?hl=ja&q=space+alt+attribute+value+IMG+element+site%3Alists.w3.org&lr=
暇があったら↑これ一通り見てみて。
今ちょっと体調不良なんで、自分で見る気力がない。
ちなみに W3C の Ian Jacobs が投げている
ttp://lists.w3.org/Archives/Public/wai-wcag-editor/2001OctDec/0008.html
がそのものズバリなのだが、特にレスは付いていない模様。
843 ：Name_Not_Found：02/05/26 18:22 ID:yyXmFBRI
>>840
>文章でもそれが装飾であれば CSS のコンテンツプロパティを使うべきだし
煽りでも何でも無いんだ。装飾のための文章なんてあるの？
文章はあくまでもコンテンツの一部であって内容でしょ？
>画像でも、文書構造に含まれるようなものならばHTMLに書かないと寧ろ駄目
これはわかる。
>これって、全然strictとは関係の無い論拠だよな(やる「手段」がない、
>と言っている訳でstrictな思想とは関係ない訳だろ)。
いや、だからstrictなマークアップにCSSでデザインが求められるわけでしょ？
切っても切り離せない関係じゃない？別物と言われてしまえばそれまでだけど。
>strict(厳格)に”許容”はない。正しいか、正しくないか、が仕様に沿って
>判断されるだけ。
これもわかるんだけど、極論、全て<div>で囲んでみるなんてどう？
strictの文法的にはおかしくなくても変じゃん。意味なくやってる人いっぱい居るよ。
って何か説明下手だな。LANケーブルで首吊ってくるわ・・。
>文章でもそれが装飾であれば CSS のコンテンツプロパティを使うべきだし
煽りでも何でも無いんだ。装飾のための文章なんてあるの？
文章はあくまでもコンテンツの一部であって内容でしょ？
>画像でも、文書構造に含まれるようなものならばHTMLに書かないと寧ろ駄目
これはわかる。
>これって、全然strictとは関係の無い論拠だよな(やる「手段」がない、
>と言っている訳でstrictな思想とは関係ない訳だろ)。
いや、だからstrictなマークアップにCSSでデザインが求められるわけでしょ？
切っても切り離せない関係じゃない？別物と言われてしまえばそれまでだけど。
>strict(厳格)に”許容”はない。正しいか、正しくないか、が仕様に沿って
>判断されるだけ。
これもわかるんだけど、極論、全て<div>で囲んでみるなんてどう？
strictの文法的にはおかしくなくても変じゃん。意味なくやってる人いっぱい居るよ。
って何か説明下手だな。LANケーブルで首吊ってくるわ・・。
844 ：CSS質問スレ389&843：02/05/26 18:26 ID:yyXmFBRI
845 ：Name_Not_Found：02/05/26 18:36 ID:0xd/LF01
XHTML1.1 のサイトで HTML4.1 のページが1ページだけあるのって駄目ですか？
良いですよね…。
良いですよね…。
846 ：Name_Not_Found：02/05/26 20:07 ID:Gy21U8GZ
>>833
【HTML】
<h1>サイト名</h1>
【CSS】
h1{
background : url(hoge.png) no-repeat;
height : ☆px;
width: ☆px;
font-size: 0.01pt;
}
とかじゃダメ？フォントサイズ思いっきり小さくする。
でもって、hoge.pngの地の色と同じ前景色にする。
【HTML】
<h1>サイト名</h1>
【CSS】
h1{
background : url(hoge.png) no-repeat;
height : ☆px;
width: ☆px;
font-size: 0.01pt;
}
とかじゃダメ？フォントサイズ思いっきり小さくする。
でもって、hoge.pngの地の色と同じ前景色にする。
847 ：Name_Not_Found：02/05/26 20:10 ID:Gy21U8GZ
>>845
良いと思われ。ていうか、サイト全体が同じ書式で統一されていなくちゃならんルールは無い。
一個だけHTML4.1でもPDFでもNEWSMLでも何でも良いじゃん。
HTML関係は全部統一されてた方がｶｺｲｲけど。それってえてして作り手の自己満足。
そういやXHTML2.0ってどうなっちゃったんだろう。
自分のサイト、既に2.0から追加のsection要素やh要素を先取りで
入れちゃって公開準備中なのに、DTDが無くちゃ公開できないよー
良いと思われ。ていうか、サイト全体が同じ書式で統一されていなくちゃならんルールは無い。
一個だけHTML4.1でもPDFでもNEWSMLでも何でも良いじゃん。
HTML関係は全部統一されてた方がｶｺｲｲけど。それってえてして作り手の自己満足。
そういやXHTML2.0ってどうなっちゃったんだろう。
自分のサイト、既に2.0から追加のsection要素やh要素を先取りで
入れちゃって公開準備中なのに、DTDが無くちゃ公開できないよー
848 ：Name_Not_Found：02/05/26 21:17 ID:6wv0MRp+
849 ：Name_Not_Found：02/05/26 21:37 ID:sixqVYXA
>>848
イマイチ想像が付かない……。
イマイチ想像が付かない……。
850 ：Name_Not_Found：02/05/26 21:48 ID:Iq7cmi6K
【衝撃】の括弧とか。
★☆○○のホームページ☆★の星とか。
★☆○○のホームページ☆★の星とか。
851 ：CSS質問スレ389& ◆tU8iHjIU ：02/05/26 21:58 ID:yyXmFBRI
名前が香ばしいのは気にしない。
>>833
それも考えたんだ。でもやっぱりきになるんだよね、0.01pt文字が(ｗ
どっちみち0.01ptなんてやって書くのも画像オフられるのと大差ないし。
でもレスありが㌧。
>>848
漏れもイマイチ想像がつかない&どういうマークアップになるのか気になる。
<div>で囲んで<span>連発？(ｗ
取り敢えず自分で書いた833でやろうと思いまふ。画像オフにされたら・・しらんで。
お騒がせしますた&板汚しｽﾏｿ。
>>833
それも考えたんだ。でもやっぱりきになるんだよね、0.01pt文字が(ｗ
どっちみち0.01ptなんてやって書くのも画像オフられるのと大差ないし。
でもレスありが㌧。
>>848
漏れもイマイチ想像がつかない&どういうマークアップになるのか気になる。
<div>で囲んで<span>連発？(ｗ
取り敢えず自分で書いた833でやろうと思いまふ。画像オフにされたら・・しらんで。
お騒がせしますた&板汚しｽﾏｿ。
852 ：Name_Not_Found：02/05/26 22:16 ID:7cYlQPVZ
853 ：Name_Not_Found：02/05/26 22:30 ID:7cYlQPVZ
>>833
どういう経緯で、唯一であるはずのheading(：そのリソースの大見出し)のを
切り替えスクリプトで切り替えなければならないのか激しく疑問なんだが。
> >strict(厳格)に”許容”はない。正しいか、正しくないか、が仕様に沿って
> >判断されるだけ。
> これもわかるんだけど、極論、全て<div>で囲んでみるなんてどう？
> strictの文法的にはおかしくなくても変じゃん。意味なくやってる人いっぱい居るよ。
well-formedとvalid、(このスレに云う所の)strictを混同している。
切り替えスクリプトが(例えば)JavaScriptなら、>>837で何ら難しいことは
ない(というか、同じこと)だと思うがな。
どういう経緯で、唯一であるはずのheading(：そのリソースの大見出し)のを
切り替えスクリプトで切り替えなければならないのか激しく疑問なんだが。
> >strict(厳格)に”許容”はない。正しいか、正しくないか、が仕様に沿って
> >判断されるだけ。
> これもわかるんだけど、極論、全て<div>で囲んでみるなんてどう？
> strictの文法的にはおかしくなくても変じゃん。意味なくやってる人いっぱい居るよ。
well-formedとvalid、(このスレに云う所の)strictを混同している。
切り替えスクリプトが(例えば)JavaScriptなら、>>837で何ら難しいことは
ない(というか、同じこと)だと思うがな。
854 ：Name_Not_Found：02/05/26 22:40 ID:uWNIT7XG
皆さん、Netscapeｮ Communicator 4.7でも
きちんと表示できるようにしていますか？
きちんと表示できるようにしていますか？
>>841
>>811 に書いて有るじゃん。煽るならせめて過去ログ読めよ。
>>843
>strictなマークアップにCSSでデザインが求められるわけでしょ？
>切っても切り離せない関係じゃない？別物と言われてしまえばそれまでだけど。
別に、CSSを全く理解しないデフォルトスタイルのみのUAでもstrictな
マークアップは機能するし、ドキュメントデータベースとして、
一切のレイアウトなしに統計データの元としてもいい。
貴方のおっしゃる通り、全く別物。
>煽りでも何でも無いんだ。装飾のための文章なんてあるの？
アンカに対してコンテンツプロパティ使って「（訪問未）」「（訪問済）」って
表示させるとか、そういうの。
ユーザースタイルシートで使うと、エセストリクターのリンクメニューの
デザインが（仮想スタイルの字数をオーバーして）ぶっ壊れて結構面白い。
>>811 に書いて有るじゃん。煽るならせめて過去ログ読めよ。
>>843
>strictなマークアップにCSSでデザインが求められるわけでしょ？
>切っても切り離せない関係じゃない？別物と言われてしまえばそれまでだけど。
別に、CSSを全く理解しないデフォルトスタイルのみのUAでもstrictな
マークアップは機能するし、ドキュメントデータベースとして、
一切のレイアウトなしに統計データの元としてもいい。
貴方のおっしゃる通り、全く別物。
>煽りでも何でも無いんだ。装飾のための文章なんてあるの？
アンカに対してコンテンツプロパティ使って「（訪問未）」「（訪問済）」って
表示させるとか、そういうの。
ユーザースタイルシートで使うと、エセストリクターのリンクメニューの
デザインが（仮想スタイルの字数をオーバーして）ぶっ壊れて結構面白い。
856 ：Name_Not_Found：02/05/26 22:53 ID:nnxRRx/2
>>854
ネスケの 4.x はCSSをオンにすると「ちゃんと表示『できない』」ブラウザなので、
CSSを使っている俺のページは俺の意図通りに「ちゃんと表示『できない』」。
ちなみにWinIE3とかでも、俺の意図通りに「ちゃんと表示『できない』」筈（試した事ないが）。
まぁ要するに遠回りなbugブラウザの排斥運動ですな。
ネスケの 4.x はCSSをオンにすると「ちゃんと表示『できない』」ブラウザなので、
CSSを使っている俺のページは俺の意図通りに「ちゃんと表示『できない』」。
ちなみにWinIE3とかでも、俺の意図通りに「ちゃんと表示『できない』」筈（試した事ないが）。
まぁ要するに遠回りなbugブラウザの排斥運動ですな。
857 ：Name_Not_Found：02/05/26 22:57 ID:7cYlQPVZ
>>854 既出の議論
>>855
> 別に、CSSを全く理解しないデフォルトスタイルのみのUAでもstrictな
> マークアップは機能するし、ドキュメントデータベースとして、
> 一切のレイアウトなしに統計データの元としてもいい。
激しく同意というより、>>833はMosaic系の所謂HTMLブラウザしか
想定していないというか
>>855
> 別に、CSSを全く理解しないデフォルトスタイルのみのUAでもstrictな
> マークアップは機能するし、ドキュメントデータベースとして、
> 一切のレイアウトなしに統計データの元としてもいい。
激しく同意というより、>>833はMosaic系の所謂HTMLブラウザしか
想定していないというか
858 ：Name_Not_Found：02/05/26 23:04 ID:0xd/LF01
859 ：Name_Not_Found：02/05/26 23:08 ID:7cYlQPVZ
>>856
不正確なことを言わないでくだちい
不正確なことを言わないでくだちい
860 ：Name_Not_Found：02/05/26 23:32 ID:Gy21U8GZ
>>857
> 激しく同意というより、>>833はMosaic系の所謂HTMLブラウザしか
> 想定していないというか
それはそれで全く問題ないんじゃない？
HTMLがStrictでさえあれば。
CSSで何やろうと、所詮はHTMLブラウザ向けのもの処置に過ぎないのだし。
> 激しく同意というより、>>833はMosaic系の所謂HTMLブラウザしか
> 想定していないというか
それはそれで全く問題ないんじゃない？
HTMLがStrictでさえあれば。
CSSで何やろうと、所詮はHTMLブラウザ向けのもの処置に過ぎないのだし。
861 ：Name_Not_Found：02/05/26 23:35 ID:QILP3df5
862 ：Name_Not_Found：02/05/26 23:48 ID:7cYlQPVZ
>>861
同意。さらに擦れ違い承知で書けばCSSで音声・点字ブラウザの制御が
できる時期になれば、(限度はあるにせよ)なおさら意味をきちんと
マーク付けした文章が必要になる。そのためのstrict思考。
同意。さらに擦れ違い承知で書けばCSSで音声・点字ブラウザの制御が
できる時期になれば、(限度はあるにせよ)なおさら意味をきちんと
マーク付けした文章が必要になる。そのためのstrict思考。
お騒がせしております。833です。
レスを付けたいのですが、どなたかノータリンの私にもわかるようにご説明
くださらぬか。
・strictなマークアップとvalidなマークアップの違いについて。
strictなマークアップがvalidであるというのは理解しております。
しかしながら必ずしもvalid=strictであるという訳では無いという事ですか？
仕様書読み直してこいとは言わないで下さい（・∀・；）
レスを付けたいのですが、どなたかノータリンの私にもわかるようにご説明
くださらぬか。
・strictなマークアップとvalidなマークアップの違いについて。
strictなマークアップがvalidであるというのは理解しております。
しかしながら必ずしもvalid=strictであるという訳では無いという事ですか？
仕様書読み直してこいとは言わないで下さい（・∀・；）
864 ：Name_Not_Found：02/05/27 00:00 ID:kDQTbZ3k
865 ：まとめたぞ ◆/Re6aTC. ：02/05/27 00:01 ID:6oY+5Pc8
Strict : 廃止予定の要素を含まない
Transitional : 廃止予定も含む
Valid : strict であっても Transitional でも、文法的に正しい
という風に思っている。違うのかな。
Transitional : 廃止予定も含む
Valid : strict であっても Transitional でも、文法的に正しい
という風に思っている。違うのかな。
866 ：Name_Not_Found：02/05/27 00:04 ID:pYIINhH7
867 ：Name_Not_Found：02/05/27 00:08 ID:J4+KY/v2
>>845
> HTML4.1 のページが1ページだけあるのって
絶 対 に 駄 目 で す 。(バージョンの捏造禁止)
>>847
> DTD が無くちゃ公開できないよー
DTD 書いたらいいのでは?
>>863
> しかしながら必ずしもvalid=strictであるという訳では無いという事ですか？
HTML 4.01 Transitional なら <p><font color="blue">ほげ</font></p> は
"valid" だけど、これは "strict" なマークアップではない。
valid: DTD に適合している。文法的に間違いがない。
strict: 用途に則った使用がなされている。
> HTML4.1 のページが1ページだけあるのって
絶 対 に 駄 目 で す 。(バージョンの捏造禁止)
>>847
> DTD が無くちゃ公開できないよー
DTD 書いたらいいのでは?
>>863
> しかしながら必ずしもvalid=strictであるという訳では無いという事ですか？
HTML 4.01 Transitional なら <p><font color="blue">ほげ</font></p> は
"valid" だけど、これは "strict" なマークアップではない。
valid: DTD に適合している。文法的に間違いがない。
strict: 用途に則った使用がなされている。
>>864
さすがにそこまで馬鹿ではないです(ｗ
>>865
えぇっとですね、>>866氏の言う通りこのスレ的なstrictです。
でもレス有り難うです。
>>866
私へのレスですよね？やっぱそうなりますか。う～む・・・。
>>867
用途に則ったっていうのは見出しにはhn、定義にはdl,dt,dd、リストには
ul,ol,liを使うという事ですよね？それも理解してるんです。
なんでしょうね、多分divの使い方に悩んでるのかもしれません。はい。
さすがにそこまで馬鹿ではないです(ｗ
>>865
えぇっとですね、>>866氏の言う通りこのスレ的なstrictです。
でもレス有り難うです。
>>866
私へのレスですよね？やっぱそうなりますか。う～む・・・。
>>867
用途に則ったっていうのは見出しにはhn、定義にはdl,dt,dd、リストには
ul,ol,liを使うという事ですよね？それも理解してるんです。
なんでしょうね、多分divの使い方に悩んでるのかもしれません。はい。
869 ：Name_Not_Found：02/05/27 00:20 ID:LvXJZ5wA
>>861
何故？HTMLでデタラメやろうとは誰も言っていないのに．
HTMLはキチンと書く．それは基本．
その上で，CSSで視覚効果狙って，たとえ見出しを非表示に
したって構わないでしょう．CSSの作りがHTMLの厳密さを
左右する訳ではないのだから．
何故？HTMLでデタラメやろうとは誰も言っていないのに．
HTMLはキチンと書く．それは基本．
その上で，CSSで視覚効果狙って，たとえ見出しを非表示に
したって構わないでしょう．CSSの作りがHTMLの厳密さを
左右する訳ではないのだから．
870 ：Name_Not_Found：02/05/27 00:24 ID:kDQTbZ3k
871 ：Name_Not_Found：02/05/27 00:25 ID:8Mo78eWu
872 ：Name_Not_Found：02/05/27 00:25 ID:LvXJZ5wA
極論すれば，HTML文書自体がキチンと正しい‐文法的にも正しく，
要素の使い方も適性である‐ならば，たとえそこに適用するCSSが
body内全要素非表示にした上で，本文含め表示全てを背景画像
１枚で示すようなものだったとしても，HTMLはStrictであると言える筈．
要素の使い方も適性である‐ならば，たとえそこに適用するCSSが
body内全要素非表示にした上で，本文含め表示全てを背景画像
１枚で示すようなものだったとしても，HTMLはStrictであると言える筈．
873 ：Name_Not_Found：02/05/27 00:27 ID:kDQTbZ3k
874 ：Name_Not_Found：02/05/27 00:31 ID:pYIINhH7
>>868
敢えてわかりやすい記述のサイトを挙げるなら神崎氏のサイトかなぁ。
>>LvXJZ5wA
# 機械的に生み出されるHTMLは少しアプローチが
# 変わってくるが、原則として
文書がそこにあって、それをマーク付けする。それで終わり。
その後、必要があればスタイルシートやスクリプトを用意する。
という考え方の問題。それを重んじるかそうでないかの違い。
敢えてわかりやすい記述のサイトを挙げるなら神崎氏のサイトかなぁ。
>>LvXJZ5wA
# 機械的に生み出されるHTMLは少しアプローチが
# 変わってくるが、原則として
文書がそこにあって、それをマーク付けする。それで終わり。
その後、必要があればスタイルシートやスクリプトを用意する。
という考え方の問題。それを重んじるかそうでないかの違い。
875 ：Name_Not_Found：02/05/27 00:32 ID:LvXJZ5wA
>>873
文句はこの人に言ってください．↓
861 名前：Name_Not_Found 投稿日：02/05/26 23:35 ID:QILP3df5
>>860
＞CSSで何やろうと、所詮はHTMLブラウザ向けのもの処置に過ぎないのだし。
この考え方がStrictではない。
私はこの人の意見に反論して，「CSSがどうであろうとHTMLが厳密なら
Strict」と当然のことを主張したまで．
文句はこの人に言ってください．↓
861 名前：Name_Not_Found 投稿日：02/05/26 23:35 ID:QILP3df5
>>860
＞CSSで何やろうと、所詮はHTMLブラウザ向けのもの処置に過ぎないのだし。
この考え方がStrictではない。
私はこの人の意見に反論して，「CSSがどうであろうとHTMLが厳密なら
Strict」と当然のことを主張したまで．
876 ：Name_Not_Found：02/05/27 00:42 ID:kDQTbZ3k
>>875
御意。
御意。
>>875
ﾊｱ?
>>833以降の文脈で
「CSSで何やろうと」なんていったらHTMLのマークアップが
崩れるのは自明じゃないか。
それを後付けでHTMLがStrictであるのが前提の上で
話をされても困る上にスレ違い。
ﾊｱ?
>>833以降の文脈で
「CSSで何やろうと」なんていったらHTMLのマークアップが
崩れるのは自明じゃないか。
それを後付けでHTMLがStrictであるのが前提の上で
話をされても困る上にスレ違い。
878 ：Name_Not_Found：02/05/27 00:58 ID:pYIINhH7
>>864 もう一度冷静にログを読み返してみてください
>>877
LvXJZ5wAが途中で論旨の摩り替えをしているので
そもそも議論の成り立ち様がないんですが、
> >>833以降の文脈で
> 「CSSで何やろうと」なんていったらHTMLのマークアップが
> 崩れるのは自明じゃないか。
>
> それを後付けでHTMLがStrictであるのが前提の上で
> 話をされても困る上にスレ違い。
自分も、てっきり彼はスタイルシート前提に話をしていて
strictな話題と関係のないことを言っていると考えていました
>>877
LvXJZ5wAが途中で論旨の摩り替えをしているので
そもそも議論の成り立ち様がないんですが、
> >>833以降の文脈で
> 「CSSで何やろうと」なんていったらHTMLのマークアップが
> 崩れるのは自明じゃないか。
>
> それを後付けでHTMLがStrictであるのが前提の上で
> 話をされても困る上にスレ違い。
自分も、てっきり彼はスタイルシート前提に話をしていて
strictな話題と関係のないことを言っていると考えていました
すいません・・。何やら私自身が荒らしみたいになってしまったようです。
一先ず今日は退散しまして、暫くロムします。
取り合えずマターリして下さい。おながいします。
お茶入れました。
￣￣￣￣￣∨￣￣￣￣￣
∧w∧
(*ﾟーﾟ) ∬
/ ⊃旦
～（＿＿）
一先ず今日は退散しまして、暫くロムします。
取り合えずマターリして下さい。おながいします。
お茶入れました。
￣￣￣￣￣∨￣￣￣￣￣
∧w∧
(*ﾟーﾟ) ∬
/ ⊃旦
～（＿＿）
880 ：Name_Not_Found：02/05/27 01:15 ID:ZG+nQDVg
いただこう
881 ：Name_Not_Found：02/05/27 01:21 ID:mjvTMoqv
＞＞８６７
ああ、HTML4.1じゃなくて4.01だって意味ね。
なぜダメなのか考えちゃった。
ああ、HTML4.1じゃなくて4.01だって意味ね。
なぜダメなのか考えちゃった。
882 ：Name_Not_Found：02/05/27 01:23 ID:jeFMzCrY
>>873
CSSが主題の話をするのはスレ違いとは思うが、
strictに関連して、例えばstrictと非strictでCSSがこうかわるとか、
スクリプト処理がこう変わる、と言う話題は(飽くまでstrictが主題と言う前提で)
ありの筈。
で、>>872はstrictを主題にしているのでちょっと言い過ぎだと思うのだがどうか。
>>1の関連スレにも /* CSS、スタイルシート質問スレッド【6】 */ が載っている訳だし。
CSSが主題の話をするのはスレ違いとは思うが、
strictに関連して、例えばstrictと非strictでCSSがこうかわるとか、
スクリプト処理がこう変わる、と言う話題は(飽くまでstrictが主題と言う前提で)
ありの筈。
で、>>872はstrictを主題にしているのでちょっと言い過ぎだと思うのだがどうか。
>>1の関連スレにも /* CSS、スタイルシート質問スレッド【6】 */ が載っている訳だし。
883 ：Name_Not_Found：02/05/27 01:32 ID:pYIINhH7
884 ：Name_Not_Found：02/05/27 08:31 ID:LvXJZ5wA
>>877さん，あなた860じゃないでしょ．860は私が書いたんだから．
>>861が突っ込んでいる元の文章をよく読んでね．↓
860 名前：Name_Not_Found 投稿日：02/05/26 23:32 ID:Gy21U8GZ
>>857
> 激しく同意というより、>>833はMosaic系の所謂HTMLブラウザしか
> 想定していないというか
それはそれで全く問題ないんじゃない？
HTMLがStrictでさえあれば。
CSSで何やろうと、所詮はHTMLブラウザ向けのもの処置に過ぎないのだし。
「HTMLがStrict」という前提で話をしているのに，それはStrictではない
と突っ込んできた>>861に対する反論が>>869 >>872．
>>861が突っ込んでいる元の文章をよく読んでね．↓
860 名前：Name_Not_Found 投稿日：02/05/26 23:32 ID:Gy21U8GZ
>>857
> 激しく同意というより、>>833はMosaic系の所謂HTMLブラウザしか
> 想定していないというか
それはそれで全く問題ないんじゃない？
HTMLがStrictでさえあれば。
CSSで何やろうと、所詮はHTMLブラウザ向けのもの処置に過ぎないのだし。
「HTMLがStrict」という前提で話をしているのに，それはStrictではない
と突っ込んできた>>861に対する反論が>>869 >>872．
885 ：Name_Not_Found：02/05/27 08:34 ID:LvXJZ5wA
886 ：Name_Not_Found：02/05/27 08:42 ID:f2tmIp7l
まあ、落ち着け
887 ：Name_Not_Found：02/05/27 10:15 ID:/ZEgq9Es
>>833の茶を飲め。
888 ：Name_Not_Found：02/05/27 11:00 ID:/ZEgq9Es
889 ：Name_Not_Found：02/05/27 11:20 ID:9ek0SPVX
日記を書くときに標準的なタグ使いってどういう感じ？
890 ：Name_Not_Found：02/05/27 11:33 ID:/ZEgq9Es
>>889
良くあるのが
<hn>日記</hn>
<hn+1>2002-05-27 ホゲホゲ</hn+1>
<p>ほにゃららがどーこー。</p>
とか
<hn>日記</hn>
<dl>
<dt>2002-05-27 ホゲホゲ</dt>
<dd><p>ほにゃららがどーこー。</p></dd>
</dl>
とかだね。で、ホゲホゲのところにid打つのが一般的かと。
良くあるのが
<hn>日記</hn>
<hn+1>2002-05-27 ホゲホゲ</hn+1>
<p>ほにゃららがどーこー。</p>
とか
<hn>日記</hn>
<dl>
<dt>2002-05-27 ホゲホゲ</dt>
<dd><p>ほにゃららがどーこー。</p></dd>
</dl>
とかだね。で、ホゲホゲのところにid打つのが一般的かと。
891 ：Name_Not_Found：02/05/27 14:09 ID:2ASOnOq0
最近xhtml basicにほれた
このぐらいシンプルでも何の問題もない
このぐらいシンプルでも何の問題もない
892 ：Name_Not_Found：02/05/27 16:18 ID:dwshtg12
>>891
携帯が対応してくれれば使うんだけどね…。
携帯が対応してくれれば使うんだけどね…。
893 ：Name_Not_Found：02/05/27 18:42 ID:Pkk4PmF7
定義を、ol、liで囲むことはなぜ出来ないですか？
894 ：Name_Not_Found：02/05/27 19:15 ID:dwshtg12
>>893
将来的には出来るようになるんじゃなかったっけ？
将来的には出来るようになるんじゃなかったっけ？
895 ：Name_Not_Found：02/05/27 19:36 ID:ZPCt/r98
>>894
将来の話は誰にも解りません。せめて草案くらい出ないことには。
将来の話は誰にも解りません。せめて草案くらい出ないことには。
896 ：388：02/05/27 20:15 ID:GPSXojK+
<h1>十大弟子</h1>
<dl>
<dt>十大弟子</dt>
<dd>イエスの10人の弟子のこと。</dd>
<ol>
<li><dt>ヤコブ</dt>
<dd></dd></li>
<li><dt>ユダ</dt>
<dd></dd></li>
</ol>
</dl>
こんなふうにしたいのですが、今は
こういう風に出来ません。
どのように、定義に番号をつければ良いですか？
普通に、数字を入力したら良いですか？
CCCC
<dl>
<dt>十大弟子</dt>
<dd>イエスの10人の弟子のこと。</dd>
<ol>
<li><dt>ヤコブ</dt>
<dd></dd></li>
<li><dt>ユダ</dt>
<dd></dd></li>
</ol>
</dl>
こんなふうにしたいのですが、今は
こういう風に出来ません。
どのように、定義に番号をつければ良いですか？
普通に、数字を入力したら良いですか？
CCCC
897 ：Name_Not_Found：02/05/27 20:26 ID:yQnXchVe
898 ：Name_Not_Found：02/05/27 22:36 ID:4IP9Pc/c
899 ：Name_Not_Found：02/05/27 23:02 ID:LvXJZ5wA
>>896
<h1>十大弟子</h1>
<dl>
<dt>十大弟子</dt>
<dd>イエスの10人の弟子のこと。
<ol>
<li>
<dl>
<dt>ヤコブ</dt>
<dd>ほにゃらら</dd>
</dl>
</li>
<li>
<dl>
<dt>ユダ</dt>
<dd>ぺけぺけ</dd>
</dl>
</li>
</ol>
</dd>
</dl>
これじゃダメ？
<h1>十大弟子</h1>
<dl>
<dt>十大弟子</dt>
<dd>イエスの10人の弟子のこと。
<ol>
<li>
<dl>
<dt>ヤコブ</dt>
<dd>ほにゃらら</dd>
</dl>
</li>
<li>
<dl>
<dt>ユダ</dt>
<dd>ぺけぺけ</dd>
</dl>
</li>
</ol>
</dd>
</dl>
これじゃダメ？
900 ：Name_Not_Found：02/05/27 23:09 ID:LvXJZ5wA
或いはこれでも良いな
<h1>十大弟子</h1>
<dl>
<dt>十大弟子</dt>
<dd>イエスの10人の弟子のこと。
<ol>
<li>
<h2>ヤコブ</h2>
<p>ほにゃ</p>
</li>
<li>
<h2>ユダ</h2>
<p>ぺけ</p>
</li>
</ol>
</dd>
</dl>
<h1>十大弟子</h1>
<dl>
<dt>十大弟子</dt>
<dd>イエスの10人の弟子のこと。
<ol>
<li>
<h2>ヤコブ</h2>
<p>ほにゃ</p>
</li>
<li>
<h2>ユダ</h2>
<p>ぺけ</p>
</li>
</ol>
</dd>
</dl>
901 ：Name_Not_Found：02/05/27 23:27 ID:fTpOPUUT
902 ：Name_Not_Found：02/05/28 07:06 ID:tIXjbYzy
>>901
何？それ
何？それ
903 ：Name_Not_Found：02/05/28 08:51 ID:yy+U2jJz
ISO HTMLでは？
904 ：Name_Not_Found：02/05/28 09:39 ID:Zme5kA7S
>>892
あれ携帯はXHTML basicで書いたら不都合があるんですか
あれ携帯はXHTML basicで書いたら不都合があるんですか
905 ：Name_Not_Found：02/05/28 10:33 ID:WmZFY/bV
>>904
少なくとも、今の503iシリーズは最初のXML宣言を解釈できない。
確かJ-PHONEの動画が取れる一番新しい機種はXML宣言を解釈できた。
（昨日確認した、というか友達が買ったから）
んで、次の504iだと恐らくXML宣言解釈できると思うけど…。
ま、解釈できないって言っても支障はないけどね。うん。
それだったらHTML4.01Strictを使った方が良いかな、と。
少なくとも、今の503iシリーズは最初のXML宣言を解釈できない。
確かJ-PHONEの動画が取れる一番新しい機種はXML宣言を解釈できた。
（昨日確認した、というか友達が買ったから）
んで、次の504iだと恐らくXML宣言解釈できると思うけど…。
ま、解釈できないって言っても支障はないけどね。うん。
それだったらHTML4.01Strictを使った方が良いかな、と。
906 ：Name_Not_Found：02/05/28 11:38 ID:1SSdz4rq
907 ：Name_Not_Found：02/05/28 12:59 ID:4Jvm6zVw
>>906
解釈できないから無視しているのではなくて？
解釈できないから無視しているのではなくて？
908 ：Name_Not_Found：02/05/28 17:05 ID:+N38PY/O
解釈しない奴だと
画面にそのまま表示されるんだよ
画面にそのまま表示されるんだよ
909 ：Name_Not_Found：02/05/28 18:09 ID:4Jvm6zVw
えーとつまり、XML宣言が表示されちゃうんだよね？
910 ：Name_Not_Found：02/05/28 19:36 ID:97vI1LZI
>>902
ISOではbody直下にしかHn要素を置けないのです。
フラットでリニアなページを目指しておるのです。
しかるにISO使いではないばけらさんも
http://www.ne.jp/asahi/minazuki/bakera/html/css/font
のようにプロパティ名はh3でタグつけしてあるのですが、下のDIV
の中ではなく前にh3を記述してあるんです。ウィンドを狭めるとそれがわかるはず。
前までDIVの中だったのでばけら氏もISOの激STRICTの教えに従ったのでしょうか？
ISOではbody直下にしかHn要素を置けないのです。
フラットでリニアなページを目指しておるのです。
しかるにISO使いではないばけらさんも
http://www.ne.jp/asahi/minazuki/bakera/html/css/font
のようにプロパティ名はh3でタグつけしてあるのですが、下のDIV
の中ではなく前にh3を記述してあるんです。ウィンドを狭めるとそれがわかるはず。
前までDIVの中だったのでばけら氏もISOの激STRICTの教えに従ったのでしょうか？
911 ：Name_Not_Found：02/05/28 20:23 ID:1SSdz4rq
912 ：Name_Not_Found：02/05/28 20:37 ID:SPqo8wmA
>>910
<div class="section">
<hn>hoge<hn>
<p>hoge</p>
</div>
と
<hn>hoge<hn>
<div class="section">
<p>hoge</p>
</div>
って純粋なHTMLとしては（DOM とか CSS の都合抜きに）どう違うの？
確かに１つの文書のなかで両方のパターンが存在すると感情的に気持ち悪いけど、
後者だからってISOを連想するは過敏じゃないか？
まぁ前者だと確実にISO派じゃないってのは解るが。
<div class="section">
<hn>hoge<hn>
<p>hoge</p>
</div>
と
<hn>hoge<hn>
<div class="section">
<p>hoge</p>
</div>
って純粋なHTMLとしては（DOM とか CSS の都合抜きに）どう違うの？
確かに１つの文書のなかで両方のパターンが存在すると感情的に気持ち悪いけど、
後者だからってISOを連想するは過敏じゃないか？
まぁ前者だと確実にISO派じゃないってのは解るが。
最初から後者ならまあそうだが
わざわざ前者から後者にかえたのであればISO系の思想が影響しているのではないかな？
と思ったまでです。てか実際body直下にhnをおいたほうがstrictなんでしょうか？
わざわざ前者から後者にかえたのであればISO系の思想が影響しているのではないかな？
と思ったまでです。てか実際body直下にhnをおいたほうがstrictなんでしょうか？
914 ：Name_Not_Found：02/05/28 20:55 ID:kF3Qz46B
sectionする時は見出しも含めた方が構造的に自然だと思う
915 ：Name_Not_Found：02/05/28 21:16 ID:1SSdz4rq
文書構成に対する考え方の差だと思う。
前者は、文書が章・節から構成されていて、各章・節が見出しを持っている、という立場。
後者は、文書が見出しと本文から構成されている、という立場。
…とか。
>>913
> ISO系の思想
ISO ってどういう根拠で見出しが BODY 直下なんだっけ？ 探せない(欝
前者は、文書が章・節から構成されていて、各章・節が見出しを持っている、という立場。
後者は、文書が見出しと本文から構成されている、という立場。
…とか。
>>913
> ISO系の思想
ISO ってどういう根拠で見出しが BODY 直下なんだっけ？ 探せない(欝
916 ：Name_Not_Found：02/05/28 21:32 ID:xIJ4bCb4
>>915
俺の想像にすぎないけど、body直下以外のブロック要素の中にhnを置くのは
望ましくない場合が多いが、「この場合はOK、この場合はだめ」といちいち
分別するのは難しいし、議論が分かれるところもありそうだから、とりあえず
「body直下以外は全部だめ」としておけば、構造上strictな文書がvalidと
認められなくなることはあっても、逆（構造上strictな文書がvalidと認められて
しまう）はなかろう……という理由では。
俺の想像にすぎないけど、body直下以外のブロック要素の中にhnを置くのは
望ましくない場合が多いが、「この場合はOK、この場合はだめ」といちいち
分別するのは難しいし、議論が分かれるところもありそうだから、とりあえず
「body直下以外は全部だめ」としておけば、構造上strictな文書がvalidと
認められなくなることはあっても、逆（構造上strictな文書がvalidと認められて
しまう）はなかろう……という理由では。
918 ：Name_Not_Found：02/05/28 22:15 ID:dFB8eGne
919 ：Name_Not_Found：02/05/28 22:27 ID:MoQ6Ee94
920 ：Name_Not_Found：02/05/28 22:44 ID:5jy3fR7s
>>915
> ISO ってどういう根拠で見出しが BODY 直下なんだっけ？ 探せない(欝
見出しの順序の検証をしようとするとそうせざるを得ないから、というのが大方の見解。
積極的に h1-h6 をブロック要素から外す理由はないものと思われ。
あと未だに「フラットでリニア」の意味が分かりません。誰か教えれ。
> ISO ってどういう根拠で見出しが BODY 直下なんだっけ？ 探せない(欝
見出しの順序の検証をしようとするとそうせざるを得ないから、というのが大方の見解。
積極的に h1-h6 をブロック要素から外す理由はないものと思われ。
あと未だに「フラットでリニア」の意味が分かりません。誰か教えれ。
921 ：Name_Not_Found：02/05/28 22:55 ID:ULOAa8hS
>>915
>>918の補足。
ISOは見出しの厳密なチェックの為にh1-h6に対応したdiv1-div6と言う要素を
導入して、h1直後にdiv1が有って、div1がh1の範囲を限定することにより見出しの
階層をチェックしている。
が、ISOはHTML4.01Strictのサブセットととして作られているのでdiv1-div6
なんて新しい要素は作れない。仕方がないので、仮想的にそのようなものがあると
して見出しのチェックを行っている。
で、こう言う前提でDTDを記述すると、DTDの表記の限界からh1-h6をbody直下に
置く、と言う制約を付けざるを得なかった、ってな感じ（我ながら荒っぽい説明だ）。
まぁ、もしDTDが読めるようならISO-HTMLのDTDを読んでみて下さい。
ちなみに、今やXML+XLSTが有るので、div1-div6だろうが、XHTMLを先取りした
section/hだろうが「記述」の拡張と制限ならやりたい放題。
個人的な見解だがISOのXML版が現れないので、こういった理由で不要だからでは
ないかと。
>>918の補足。
ISOは見出しの厳密なチェックの為にh1-h6に対応したdiv1-div6と言う要素を
導入して、h1直後にdiv1が有って、div1がh1の範囲を限定することにより見出しの
階層をチェックしている。
が、ISOはHTML4.01Strictのサブセットととして作られているのでdiv1-div6
なんて新しい要素は作れない。仕方がないので、仮想的にそのようなものがあると
して見出しのチェックを行っている。
で、こう言う前提でDTDを記述すると、DTDの表記の限界からh1-h6をbody直下に
置く、と言う制約を付けざるを得なかった、ってな感じ（我ながら荒っぽい説明だ）。
まぁ、もしDTDが読めるようならISO-HTMLのDTDを読んでみて下さい。
ちなみに、今やXML+XLSTが有るので、div1-div6だろうが、XHTMLを先取りした
section/hだろうが「記述」の拡張と制限ならやりたい放題。
個人的な見解だがISOのXML版が現れないので、こういった理由で不要だからでは
ないかと。
>>916-921
つまり、見出しを body 直下以外に置けない理由は
「DTD で表現できない」とか
「body 直下以外に置けなくなることよりも見出し階層の整合性を重視」といった
消極的根拠、てな理解でいいんだろうか。
つまり、見出しを body 直下以外に置けない理由は
「DTD で表現できない」とか
「body 直下以外に置けなくなることよりも見出し階層の整合性を重視」といった
消極的根拠、てな理解でいいんだろうか。
>>922
はっきりそう書かれた文書を俺は読んだ事ないんだが、DTDなど周辺事情から
考えると、ほぼそうと言い切れる。仮にHTML4.01のサブセットと言う
制約を外していたらdiv1-div6が記述されるべき要素として存在していたはず。
はっきりそう書かれた文書を俺は読んだ事ないんだが、DTDなど周辺事情から
考えると、ほぼそうと言い切れる。仮にHTML4.01のサブセットと言う
制約を外していたらdiv1-div6が記述されるべき要素として存在していたはず。
924 ：Name_Not_Found：02/05/29 06:18 ID:kTRlhUY5
>915
自分はsectionとheadingの関係は
fieldsetとlegendの関係と同じだと思っているので、
前者の立場に賛同です。
自分はsectionとheadingの関係は
fieldsetとlegendの関係と同じだと思っているので、
前者の立場に賛同です。
何やら妙な憶測が蔓延してるようなので、ちょっと長くなりますがこの際
ISO-HTML が何故こういうデザインに至ったかをまとめておきます。詳細は
ISO/IEC JTC1/SC18/WG8 (現在は JTC1/WG4) の Web サイトを見れば関連文書を
参照できます。以下では "N1898" のような記述は ISO/IEC JTC1/SC18/WG8 の
Document Number を指します。
cf. http://www.ornl.gov/sgml/wg8/
ISO-HTML は1996年11月に ISO/IEC JTC1/SC18 の作業アイテムとして承認され、
IETF や W3C との協力のもと、1997年当初は W3C の HTML 3.2 をベースに
IETF の RFC 2070 で提案された国際化機能や HTML 2.0 (RFC 1866) にあった
ICADD サポートなどを取り込みつつ、PLAINTEXT のような SGML で表現
できない機能や FONT のように推奨されない機能は取り除くなど、比較的
独自の路線を取っていました。当初の ISO-HTML で追加された機能の中で
最も特徴的だったのは厳密なセクションのネストを強制する要素の追加で、
N1898 でわざわざ簡潔な手法を取る (Hx とそれに対応する Bx を用いる) か
明示的にセクション構造を示す Sx 要素を導入するか意見を求めていること
からも、いかに厳密なセクションのネストにこだわっていたかがわかります。
後者の場合には Sx でセクションを明示すべきで DIV は将来的には削除すべき
かもしれない、とまで言っています。
ISO-HTML が何故こういうデザインに至ったかをまとめておきます。詳細は
ISO/IEC JTC1/SC18/WG8 (現在は JTC1/WG4) の Web サイトを見れば関連文書を
参照できます。以下では "N1898" のような記述は ISO/IEC JTC1/SC18/WG8 の
Document Number を指します。
cf. http://www.ornl.gov/sgml/wg8/
ISO-HTML は1996年11月に ISO/IEC JTC1/SC18 の作業アイテムとして承認され、
IETF や W3C との協力のもと、1997年当初は W3C の HTML 3.2 をベースに
IETF の RFC 2070 で提案された国際化機能や HTML 2.0 (RFC 1866) にあった
ICADD サポートなどを取り込みつつ、PLAINTEXT のような SGML で表現
できない機能や FONT のように推奨されない機能は取り除くなど、比較的
独自の路線を取っていました。当初の ISO-HTML で追加された機能の中で
最も特徴的だったのは厳密なセクションのネストを強制する要素の追加で、
N1898 でわざわざ簡潔な手法を取る (Hx とそれに対応する Bx を用いる) か
明示的にセクション構造を示す Sx 要素を導入するか意見を求めていること
からも、いかに厳密なセクションのネストにこだわっていたかがわかります。
後者の場合には Sx でセクションを明示すべきで DIV は将来的には削除すべき
かもしれない、とまで言っています。
結果的には N1902 で B1 - B6 要素を導入する立場を採用し、1997年3月には
早くも CD (Committee Draft) 投票が行われましたが、N1934 にまとめられて
いるように各国の National Body の反応は独自路線で ISO 規格を制定する
よりも W3C の仕様との整合性の方を望む声が多数でした。当時はまだいわゆる
「ブラウザ戦争」が華やかなりし頃で、ISO が率先してさらなる非互換性を
生み出すのは望ましくないと考えられたからです。特に日本の National Body
は反対票を投じ、"No extension to the W3C's HTML 3.2" と言い切っていました。
cf. http://www.y-adagio.com/public/committees/wg8_jap/votes/cd_html.htm
そのため ISO では W3C の HTML 仕様と整合性を図る道を模索し、1997年7月に
ドラフトが公開された HTML 4.0 が ISO-HTML の提案に比較的近かったことも
あって HTML 3.2 ではなく HTML 4.0 をベースにすることで策定を進めました。
1997年10月の N1935 ではかなり HTML 4.0 に近くなったものの、B1 - B6 は
DIV1 - DIV6 と名前を変えて、開始タグ、終了タグともに省略可能であるものの
まだデフォルトの "Structure" DTD では実際の要素として残っていました
("NoStructure" DTD では HTML 4.0 同様 DTD 上は厳密なセクション構造は
強制されない)。
早くも CD (Committee Draft) 投票が行われましたが、N1934 にまとめられて
いるように各国の National Body の反応は独自路線で ISO 規格を制定する
よりも W3C の仕様との整合性の方を望む声が多数でした。当時はまだいわゆる
「ブラウザ戦争」が華やかなりし頃で、ISO が率先してさらなる非互換性を
生み出すのは望ましくないと考えられたからです。特に日本の National Body
は反対票を投じ、"No extension to the W3C's HTML 3.2" と言い切っていました。
cf. http://www.y-adagio.com/public/committees/wg8_jap/votes/cd_html.htm
そのため ISO では W3C の HTML 仕様と整合性を図る道を模索し、1997年7月に
ドラフトが公開された HTML 4.0 が ISO-HTML の提案に比較的近かったことも
あって HTML 3.2 ではなく HTML 4.0 をベースにすることで策定を進めました。
1997年10月の N1935 ではかなり HTML 4.0 に近くなったものの、B1 - B6 は
DIV1 - DIV6 と名前を変えて、開始タグ、終了タグともに省略可能であるものの
まだデフォルトの "Structure" DTD では実際の要素として残っていました
("NoStructure" DTD では HTML 4.0 同様 DTD 上は厳密なセクション構造は
強制されない)。
結局、1997年9月に出た HTML 4.0 のドラフトで HTML 4.0 の DTD を Strict/
Transitional/Frameset の3つに分けたこともあって、最終的には N1944 に
あるように ISO-HTML は HTML 4.0 Strict のサブセットとして定義し、
ISO-HTML DTD に適合する文書は HTML 4.0 DTD にも適合すべし、という
新たな要求項目が追加されました。従って HTML 4.0 にない要素や属性は
追加してはならないことになり、ここでも真っ先に DIV1 - DIV6 をどうする
かが課題として挙げられています。
厳密なセクション構造を諦めきれない ISO-HTML のエディタ達は Pre-HTML
という文書準備処理を導入し、DIV1 - DIV6 は妥当な ISO-HTML 文書には
出現してはならないが Pre-HTML ではセクション構造の妥当性検証ができる
「擬似」要素として残すことにしました。この結果、妥当な ISO-HTML 文書
では見かけ上 H1 - H6 は BODY 直下に出現することになります。またこの
「擬似」構造のために見出しを DIV で囲むことができなくなってしまって
います。
Transitional/Frameset の3つに分けたこともあって、最終的には N1944 に
あるように ISO-HTML は HTML 4.0 Strict のサブセットとして定義し、
ISO-HTML DTD に適合する文書は HTML 4.0 DTD にも適合すべし、という
新たな要求項目が追加されました。従って HTML 4.0 にない要素や属性は
追加してはならないことになり、ここでも真っ先に DIV1 - DIV6 をどうする
かが課題として挙げられています。
厳密なセクション構造を諦めきれない ISO-HTML のエディタ達は Pre-HTML
という文書準備処理を導入し、DIV1 - DIV6 は妥当な ISO-HTML 文書には
出現してはならないが Pre-HTML ではセクション構造の妥当性検証ができる
「擬似」要素として残すことにしました。この結果、妥当な ISO-HTML 文書
では見かけ上 H1 - H6 は BODY 直下に出現することになります。またこの
「擬似」構造のために見出しを DIV で囲むことができなくなってしまって
います。
極論すれば ISO-HTML 策定の歴史は如何にして HTML に「フラットでリニア」
*でない* セクション構造を持ち込むかの歴史であって、誰が言い出したか
知りませんが ISO-HTML が「フラットでリニアなページを目指している」
などと言うのは本質を全く理解していません。Roger Price や David
Abrahamson (ISO-HTML のエディタ達) が聞いたら血の涙を流して悲しみ
そうです。
以上、参考までに。
*でない* セクション構造を持ち込むかの歴史であって、誰が言い出したか
知りませんが ISO-HTML が「フラットでリニアなページを目指している」
などと言うのは本質を全く理解していません。Roger Price や David
Abrahamson (ISO-HTML のエディタ達) が聞いたら血の涙を流して悲しみ
そうです。
以上、参考までに。
929 ：Name_Not_Found：02/05/29 07:56 ID:RtW8Covp
なんかよく分からんが
すごいな。
すごいな。
930 ：Name_Not_Found：02/05/29 07:58 ID:oXII6PB/
931 ：Name_Not_Found：02/05/29 08:01 ID:RtW8Covp
で
フラットでリニアって何よ？（ワ
分からないからISOがフラットでリニアを目指しているのか
目指していないのかも分からない。
フラットでリニアって何よ？（ワ
分からないからISOがフラットでリニアを目指しているのか
目指していないのかも分からない。
932 ：Name_Not_Found：02/05/29 08:28 ID:oXII6PB/
フラット（平坦）でリニア（直線）なんだから、
<div>
<ul>
<li> …… </li>
<li> …… </li>
<li> …… </li>
</ul>
<p> </p>
</div>
のような階層構造を使ってない文書、body直下に全ての要素を
置く文書のことじゃないの？
もっとも、html, head, bodyの時点で既に階層構造なんだが。
違ってたらｽﾏｿ。
<div>
<ul>
<li> …… </li>
<li> …… </li>
<li> …… </li>
</ul>
<p> </p>
</div>
のような階層構造を使ってない文書、body直下に全ての要素を
置く文書のことじゃないの？
もっとも、html, head, bodyの時点で既に階層構造なんだが。
違ってたらｽﾏｿ。
933 ：Name_Not_Found：02/05/29 09:26 ID:bkExLxUu
934 ：Name_Not_Found：02/05/29 10:59 ID:DOQT7tKz
935 ：Name_Not_Found：02/05/29 11:22 ID:CWBxYNKy
936 ：Name_Not_Found：02/05/29 11:30 ID:jRdy1cRk
>>934
フラット:
平坦。階層構造がない。
ファイルで言えば全ファイルがルートディレクトリにあるような状態。
リニア:
線形。寄り道したり、一部分だけが参照されるようなことを想定せず
先頭から順に読まれることしか考えてないような作り。
リニアでフラット:
要はマーク付けされないベタのテキストみたいな状態。
フラット:
平坦。階層構造がない。
ファイルで言えば全ファイルがルートディレクトリにあるような状態。
リニア:
線形。寄り道したり、一部分だけが参照されるようなことを想定せず
先頭から順に読まれることしか考えてないような作り。
リニアでフラット:
要はマーク付けされないベタのテキストみたいな状態。
937 ：Name_Not_Found：02/05/29 11:49 ID:SRx7xI1c
938 ：Name_Not_Found：02/05/29 22:39 ID:pYXSyysR
世界初！Strict-HTML完全対応！
その名も「ホームページ忍者」。
使えない人間は時代遅れとなる。
その名も「ホームページ忍者」。
使えない人間は時代遅れとなる。
939 ：Name_Not_Found：02/05/29 23:35 ID:SOBYS34N
みまさｾｿｾｲ解説有難うございました。
ということで、結局いつぞやの論争は XHTML 派の完全勝利ということで宜しいか?
ということで、結局いつぞやの論争は XHTML 派の完全勝利ということで宜しいか?
940 ：Name_Not_Found：02/05/29 23:41 ID:SOBYS34N
ところで
>>936
> リニア:
> 線形。寄り道したり、一部分だけが参照されるようなことを想定せず
> 先頭から順に読まれることしか考えてないような作り。
これってちゃんとした用語なの? あればソースをきぼぬ。
>>936
> リニア:
> 線形。寄り道したり、一部分だけが参照されるようなことを想定せず
> 先頭から順に読まれることしか考えてないような作り。
これってちゃんとした用語なの? あればソースをきぼぬ。
<ul>
<li><dl><dt>5/29</dt><dd>日記ウプ</dd></dl></li>
</ul>
ってできないの？
<li><dl><dt>5/29</dt><dd>日記ウプ</dd></dl></li>
</ul>
ってできないの？
942 ：Name_Not_Found：02/05/30 00:24 ID:muZpwFIF
943 ：Name_Not_Found：02/05/30 08:37 ID:8tJDxUK/
>>940
「リニア(linear)」は数学用語の「線形」ではなくて
一般形容詞の「(直)線状」と思われ。
線形(linear), 非線形(non-linear), ハイパーテキスト(hypertext)
くらいのキーで結構いろんな文書が出てくる。
「リニア(linear)」は数学用語の「線形」ではなくて
一般形容詞の「(直)線状」と思われ。
線形(linear), 非線形(non-linear), ハイパーテキスト(hypertext)
くらいのキーで結構いろんな文書が出てくる。
944 ：Name_Not_Found：02/05/30 13:50 ID:dZi4S+BS
display:none;
したボックス内の文字も音声ソフトは読み上げてくれますか？
したボックス内の文字も音声ソフトは読み上げてくれますか？
945 ：Name_Not_Found：02/05/30 14:00 ID:8tJDxUK/
>>944
スレ違い。
スレ違い。
次スレ4.0、次々スレ4.01として、その次はどうなるの？
947 ：Name_Not_Found：02/05/30 15:02 ID:8tJDxUK/
>>946
5.0 (W2C Working Draft) とか。
5.0 (W2C Working Draft) とか。
948 ：Name_Not_Found：02/05/30 15:03 ID:tgfslMN7
>946
X1 ?
X1 ?
949 ：Name_Not_Found：02/05/30 15:11 ID:FSAx86wH
950 ：Name_Not_Found：02/05/30 15:11 ID:zPcOADCe
正直、会話についていけません。
もうだめぽ。
もうだめぽ。
951 ：Name_Not_Found：02/05/30 15:13 ID:7D+XuuwL
952 ：Name_Not_Found：02/05/30 16:01 ID:+jsTZePZ
たぶんあと2スレ使い切るまでに、XHTML2あたりが出ている気もする（ｗ
953 ：Name_Not_Found：02/05/30 17:12 ID:dZi4S+BS
http://fuji.u-shizuoka-ken.ac.jp/~ishikawa/wcga.htm
ってh3のあとにh2をつかいたくないために
<span class="midasi">
って使っているの？
<h1>・・・
<h2>・・・
<h3>・・・
<h2>・・
ってよくないのですか？
ってh3のあとにh2をつかいたくないために
<span class="midasi">
って使っているの？
<h1>・・・
<h2>・・・
<h3>・・・
<h2>・・
ってよくないのですか？
954 ：Name_Not_Found：02/05/30 17:15 ID:VjhQF44p
で、このスレはなかったことになるわけだ。ｗ
955 ：950：02/05/30 17:50 ID:0LY0km0j
950が次スレ立てるのでしょうか？
・・・もうだめぽと発言しておきながらスレ立てかよ（ﾆｶﾞﾜﾗ
タイトルはStrict-HTML スレッド 4.0 (W2C Recommendation) でいいんでしょうか？
・・・もうだめぽと発言しておきながらスレ立てかよ（ﾆｶﾞﾜﾗ
タイトルはStrict-HTML スレッド 4.0 (W2C Recommendation) でいいんでしょうか？
956 ：Name_Not_Found：02/05/30 17:50 ID:EDxKcbGl
<h1>見出し</h1>
<h2>邦楽</h2>
<h3>モー娘。</h3>
<p>....</p>
<h2>洋楽</h2>
<h3>Bad Religion</h3>
<p>....</p>
っていう使い方はOKじゃないの？
<h2>邦楽</h2>
<h3>モー娘。</h3>
<p>....</p>
<h2>洋楽</h2>
<h3>Bad Religion</h3>
<p>....</p>
っていう使い方はOKじゃないの？
957 ：Name_Not_Found：02/05/30 17:51 ID:tZhVwJ4s
<h1>見出し
<h2>項目１
<h3>項目内項目１
<h3>項目内項目２
<h2>項目２
ってな入れ子関係として考えるのは駄目？
<h2>項目１
<h3>項目内項目１
<h3>項目内項目２
<h2>項目２
ってな入れ子関係として考えるのは駄目？
958 ：Name_Not_Found：02/05/30 17:53 ID:tZhVwJ4s
あ、>>956のほうが1分早い上に分かりやすい・・・
959 ：Name_Not_Found：02/05/30 18:14 ID:FSAx86wH
Strict-HTML スレッド 4.0 (W2C Recommendation)
Strict な HTML(*) について語るスレッド Version 3.2
W3C 信者もそうじゃない人も投稿歓迎。
* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
XHTML 1.1, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。
■過去ログ
1.0 http://pc.2ch.net/hp/kako/992/992708594.html
2.0 http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
3.0 http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
3.2 http://pc.2ch.net/test/read.cgi/hp/1018719800/
■関連スレ
/* CSS、スタイルシート質問スレッド【8】 */ http://pc.2ch.net/test/read.cgi/hp/1019881572/
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
W3C信者と感じる瞬間 http://mentai.2ch.net/hp/kako/990/990175066.html
W3C信者の方に質問 http://mentai.2ch.net/hp/kako/977/977621932.html
■勧告等
HTML 4.01 http://www.w3.org/TR/html401/
XHTML 1.0 http://www.w3.org/TR/xhtml1/
XHTML Basic http://www.w3.org/TR/xhtml-basic/
XHTML 1.1 http://www.w3.org/TR/xhtml11/
ISO/IEC 15445 (ISO-HTML) http://woodworm.cs.uml.edu/~rprice/15445/15445.html
JIS X 4156 (JIS-HTML) http://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳など http://www.doraneko.org/webauth/
■その他
W3C http://www.w3.org/
Another HTML-lint http://openlab.ring.gr.jp/k16/htmllint/htmllint.html
W3C HTML Validation Service http://validator.w3.org/
ごく簡単なHTMLの説明 http://kanzaki.com/docs/htminfo.html
Strict な HTML(*) について語るスレッド Version 3.2
W3C 信者もそうじゃない人も投稿歓迎。
* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
XHTML 1.1, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。
■過去ログ
1.0 http://pc.2ch.net/hp/kako/992/992708594.html
2.0 http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
3.0 http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
3.2 http://pc.2ch.net/test/read.cgi/hp/1018719800/
■関連スレ
/* CSS、スタイルシート質問スレッド【8】 */ http://pc.2ch.net/test/read.cgi/hp/1019881572/
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
W3C信者と感じる瞬間 http://mentai.2ch.net/hp/kako/990/990175066.html
W3C信者の方に質問 http://mentai.2ch.net/hp/kako/977/977621932.html
■勧告等
HTML 4.01 http://www.w3.org/TR/html401/
XHTML 1.0 http://www.w3.org/TR/xhtml1/
XHTML Basic http://www.w3.org/TR/xhtml-basic/
XHTML 1.1 http://www.w3.org/TR/xhtml11/
ISO/IEC 15445 (ISO-HTML) http://woodworm.cs.uml.edu/~rprice/15445/15445.html
JIS X 4156 (JIS-HTML) http://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳など http://www.doraneko.org/webauth/
■その他
W3C http://www.w3.org/
Another HTML-lint http://openlab.ring.gr.jp/k16/htmllint/htmllint.html
W3C HTML Validation Service http://validator.w3.org/
ごく簡単なHTMLの説明 http://kanzaki.com/docs/htminfo.html
960 ：Name_Not_Found：02/05/30 18:15 ID:FSAx86wH
961 ：Name_Not_Found：02/05/30 18:44 ID:NBmF3Lu8
962 ：Name_Not_Found：02/05/30 18:48 ID:NBmF3Lu8
Strict-HTML スレッド 4.0 (W2C Recommendation)
http://pc.2ch.net/test/read.cgi/hp/1022751972/l50
立ててきました。
本文のVersion 3.2直すの忘れました…
4.1立てる人、忘れないで下さい…
逝ってきます。
http://pc.2ch.net/test/read.cgi/hp/1022751972/l50
立ててきました。
本文のVersion 3.2直すの忘れました…
4.1立てる人、忘れないで下さい…
逝ってきます。
963 ：Name_Not_Found：02/05/30 19:02 ID:FSAx86wH
964 ：Name_Not_Found：02/05/30 19:33 ID:QJ/hB/te
4.1
965 ：Name_Not_Found：02/06/08 21:55 ID:wMR0Eok7
4.1なんか立てるなよ。
4.01に汁。
4.01に汁。
こそーり
967 ：Name_Not_Found：02/06/16 18:06 ID:fOMOMUk/
じゃ、俺もこそーり。
datおちしないか心配
969 ：Name_Not_Found：02/06/20 18:48 ID:0SaZbXKE
こそーり
970 ：j君 ：02/06/22 15:53 ID:RAcXRlJD
あと３０
結構たる
あげちゃえ
結構たる
あげちゃえ
971 ：Name_Not_Found：02/06/22 18:49 ID:d97rQp36
またやってるのかよ(w
972 ：Name_Not_Found：02/06/24 01:10 ID:ii0lAgvN
消費はしなくちゃね
973 ：Name_Not_Found：02/06/24 14:52 ID:H4VHaZGf
もぐもぐ
974 ：Name_Not_Found：02/07/04 16:39 ID:???
９７４ＧＥＴ！
975 ：Name_Not_Found：02/07/05 00:55 ID:???
くそう! 974取られたぜ!
えらくまったりした1000取り合戦だなぁ。
なあ、>>977も思うだろ？
なあ、>>977も思うだろ？
977 ：Name_Not_Found：02/07/05 03:00 ID:???
え、いえ、別に…
978 ：Name_Not_Found：02/07/05 09:01 ID:???
1000取り合戦はもっと殺伐としてるべきなんだよ。ｺﾞﾙｧ!
979 ：Name_Not_Found：02/07/05 11:02 ID:???
老若男女はすっこんでろ。ｺﾞﾙｧ!
980 ：Name_Not_Found：02/07/05 12:20 ID:???
荒らしの前の静けさってあるでしょ
981 ：Name_Not_Found：02/07/05 15:06 ID:???
９８１ＧＥＴ！
982 ：Name_Not_Found：02/07/05 16:42 ID:???
>>981=974
あげんな馬鹿 死ね
あげんな馬鹿 死ね
983 ：Name_Not_Found：02/07/05 17:44 ID:???
９８３ＧＥＴ！
984 ：Name_Not_Found：02/07/05 18:02 ID:???
終わったスレをあげるな学習能力の無いカスが
985 ：Name_Not_Found：02/07/05 18:06 ID:???
>>983=981=974
はいはい、凄いから厨房板に帰ってね
はいはい、凄いから厨房板に帰ってね
986 ：Name_Not_Found：02/07/05 18:07 ID:???
９８６ＧＥＴ！
だからあげんなって。
988 ：Name_Not_Found：02/07/05 18:12 ID:???
989 ：Name_Not_Found：02/07/05 18:21 ID:???
<!DOCUSOTYPE html PUBLIC "-//W2C//DTD HTML 2ch//EN">
990 ：Name_Not_Found：02/07/05 18:21 ID:???
<html lang="ja">
991 ：Name_Not_Found：02/07/05 18:21 ID:???
<head>
992 ：Name_Not_Found：02/07/05 18:21 ID:???
<meta http-equiv="content-type" content="text/html; charset=Shift_JIS">
993 ：せｘ：02/07/05 18:22 ID:wIeWqgSC
1000とりSTART
sage
996
996
sage
998 ：Name_Not_Found：02/07/05 18:23 ID:???
邪魔すんな
９９８ｇｅｔ
1000 ：Name_Not_Found：02/07/05 18:24 ID:???
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。