Strict-HTML スレッド 2.0 (W2C Recommendation)

Strict な HTML(*) について語るスレッド Version 2.0 。
W3C 信者もそうじゃない人も投稿歓迎。 関連スレ等は >>2-4 あたり

* 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) など。

関連スレ
　Strict-HTML スレッド(1.0)　http://pc.2ch.net/test/read.cgi/hp/992708594/-100
　CSSコミュニティの功罪を評価するスレ その２　http://pc.2ch.net/test/read.cgi/hp/1003378794/-100
　XML、XHTMLについて語り合うスレッド　http://pc.2ch.net/test/read.cgi/hp/1002461949/-100
　W3C信者と感じる瞬間　http://mentai.2ch.net/hp/kako/990/990175066.html
　W3C信者の方に質問　http://mentai.2ch.net/hp/kako/977/977621932.html
　CSSコミュニティの功罪を評価するスレ　http://natto.2ch.net/hp/kako/993/993743434.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

（　・∀・）ノ　新スレだ！

お疲れさまですた。

>>1
新スレありがとう、そしてお疲れ様。

>1
乙カレー

>>1
お疲れさまっす。
すみけん氏スレッドまで入ってるのね。

ところで、CSSで擬似段組(?)しているサイトで、

<div class="col-left">〜</div>　（註:左列）
のような記述をしているところってあるよね？あれってどうなんでしょ。

<span class="red">〜</span>
として赤い文字にしているのとあまり変わらないような気がするんだけど。
皆さんはいかが？

>>7
好ましくないとは思いますが
自分でもclass="header"とかやってるんで、
人のこと言えません。

>7
「2 段組というデザイン」のために存在するのならそういう名前でいいと思う．

＞8
それとはちょっと違うんでない？
headerならタイトルとかコンテンツだなって感じだけど
col-leftって思いっきり左寄せって感じじゃん。

見当違いならｽﾏｿ。

>>10
俺もそう思う。
>>9の言い分だと、「赤い色というデザイン」のために
class="red"が通ってしまうし。

>11
例えばカラーチャートを作って（なぜ画像にしないのかとかいうのはこの際おいといて）
赤い色をデザインとして指定したい時は？

>>10
「ヘッダ」ってことは既に視覚固定的なことを意識した名称かと思いまして。
「文書の先頭」と言う意味でヘッダだったら良いのかな。難しいですね。

>>12
例えばどのようにそのソースを記述されますか？

視覚系UAで見たときにはレイアウトの為のDIV+CSSで整形してある方が見やすいね。
トップページくらいはdivでレイアウトしないと見辛くなる気がする。

（；・∀・） まあ俺のマークアップやCSSが悪いだけなんだろうけど


>>13
head要素みたいな意味合いなら別にいいんじゃない？

＞13
あー、なるほどね。
自分はtitle, contents, mainとﾏｰｸｱﾌﾟしてるからなんとも言えんが
これも視覚的と言えば視覚的だなぁ・・・

（　・∀・）ノ そういえばテーブルで

<table><tr>
<td><img src="gazou.png"></td>
</tr><tr>
<td>画像の説明</td>
</tr></table>

というような使い方は正しいのかな？

>>16
「冗長だ」という事を除けば、良いとも悪いとも言えないような。

>>15
それって視覚情報？
立派な意味的マーク付けだと思うが。

>>16
どちらかといえば定義リストと思われ。

>>17-18
レスありがとう

やっぱりちょっと変な使い方か･･････って （；・∀・）初心者スレでもよかったかな

自分のサイトをNN4で表示なんて殆どしてなかったけど、今興味本意でやって
みた。（；・∀・）なんか恐ろしい表示になってたよ

>>20
@importで弾いとけYO!

>>20
@importを使うと N4.x(初期のもの)が落ちることがある、
という話を聞いたことがあるので、

<link rel="stylesheet" href="hoge.css" type="text/css"
　media="screen,tv,print" />

のように screen 以外に何か書くとか、media="all"として
N4.x を弾くのも一つの手だよ。
screen 用のシートしか書いてない場合にはあまりオススメできないけどね。

>13
すっかり遅くなりまして．例えば
光の三原色は<span class="red">赤</span>，<span class="green">緑</span>，
<span class="blue">青</span>である．
とか．意味としての class と言えなくもないけど，デザインとしての class とも言える．

ま，でも，自分じゃやらないけどね．他人がやっていたらそういう意味なんだろうと思うだけで．

>>23
<div class="left">左！</div>
<div class="right">右！</div>

確かにこれなら許せるが。そんな奴見たことねえ。

>24
あー確かに．意味合いが全然違うな．

えーと，では，雑誌などの 2 段組にはレイアウト以上の目的は
ないと思うけど，それを何らかの理由で HTML で実現しなきゃ
ならないとしたら？やっぱり class="left" とかにならない？
「HTML+CSS でやらない」というのはそのとおりだと思うし，僕も
個人的にはやらないけど，上からどうしてもやれと言われるとか．

あと，class="left" などが気持ち悪い，という話を一般化すると，
strict な立場としては「class 名や id 名にはレイアウト情報や
視覚（あるいは聴覚など）の効果を意味する名前をつけず，
あくまで文書中での論理構造を意味するものを付けるほうが良い」
ということでしょうか？

>>21-22
今までNN4でレイアウトが崩れるって言っても読めないほどじゃないだろ
うと思ってたけど、（　・∀・）ノ 全く読めないね。


>>25
＞雑誌などの 2 段組にはレイアウト以上の目的は
＞ないと思うけど，それを何らかの理由で HTML で実現しなきゃ
＞ならないとしたら？

（；・∀・）HTML文書でやる事じゃない気が･･････

>>25
＞えーと，では，雑誌などの 2 段組にはレイアウト以上の目的は
＞ないと思うけど，それを何らかの理由で HTML で実現しなきゃ
＞ならないとしたら？

HTMLではそんなことでけん。CSS3の勧告を待て。
http://kanzaki.com/book/html/updates.html#css3-multicol

>26-27
思考実験以上の意味を何も持たないので，もうやめます．
やったこともないことを想定して書くというのにそもそも無理があった．ごめん．

で，結局 >25 の最後についてはこういうまとめでいいの？
（まとめなくてもいい，ということかもしれないが．）

┏━━━━━━━━━━━━━━┓
┃←少ない　　　　　　　　　　　多い→┃
┗━━━━━━━━━━━━━━┛
↑見たいなテーブルの見出しをのを表現するために
<td>
<div class="left">←少ない</div>
<div class="right">多い→</div>
</td>
ってな感じで書きましたが,これってだめですか？

その場合は「 many 」と「 few 」とかのが良いんじゃないでしょうか。
例えば文字を全て縦書きで出力する UA があれば
左右ではなく上下に分かれるコトになるだろうし。

＞例えば文字を全て縦書きで出力する UA があれば
IE5.5以降なら縱書きスタイルシートもありますしね。
だったらclass="left"／class="right"ではなく
id="column1"／id="column2"とでもしておけばいいのでは。
文書を読み通す順にcol1、col2……と番号を振る。

http://www.yoshinoya-dc.com/dc/iso2/iso14001.html

の吉野家ってところ　吉って字の上の方が短いヨシが書けないのかどうか
知らんが画像を使っている。やっぱこうゆうのはよろしゅうないかな？
別にどうでもいいけどちと笑ったんで。

　吉野家ってみな字をまちがえてたんやね。

>>32
文字コードを定めたJIS X 0208の、1997年改訂で「同一の文字」だとして包摂（統合）されてしまいました。
高島屋の、所謂「はしご高」も同様。

Unicode(ISO/IEC 10646:2000)にはあるんだっけ？

>33
「よし」にはなかった
「たかい」は髙

>34
すまね，展開されちゃった．
「たかい」は＆＃39641;

>>30-31
やっぱりleft,rightはまずかったんですね。
とても参考になりました。
ありがとうございます。

ここでも16進数値文字参照を使えるようになったのか。
ちょっと感動。

& （文字実体参照）
& （10進数による数値文字参照）
& （16進数による数値文字参照）

おおっ！　素晴らしい！

¿ A donde vas ?

&をエスケープしないのはStrict的にはすばらしいことではないだろ
俺は別に信者じゃないからどっちでもいいけど

>>41
エスケープしてますよ。
ソース見てみ。&amp;（文字実体参照）ってなってるんだよ。

存在しない実体参照まで許可するようになってたら微妙にsage。
でも正しくチェックするのは面倒だよな。
テスト → &ahya;

ソース上では ＆ａｍｐ；ａｈｙａ；にならなければならないのが
やはりエスケープされてないようっすね。
♥

>>29
HTML内の位置情報を示そうとしている時点で間違い。
素直に「左が少なくて右が多い」と書けばいいじゃないか。
どうしても視覚的に表現したいならそれを画像で置き換えればいい。

と思う。

<div class="dangumi"> </div>

>>44
＆ahya;が＆amp;ahyaに変換されないのは当然。
「UAは不明な参照を展開しない」ので、CGIサイドでもブラウザサイドでも
＆ahya;を＆ahya;として出力する。
一々CGIで「この実体は定義されているか」なんてチェックしていられないでしょ。
つーか、DOCTYPE宣言無いのに実体の定義もクソもないけど(w

鳩丸のとこでもやってたが　&ontan; ってどうよ？
＆ampontan; な

MozillaもIEもOperaもLynxも＆ontan;だな。

>>48-49
iCabは正しく挙動する。NN4.xも(w

ちょいと相談。リンクページで

<dl>
　　<dt><img src="【バナー】" alt="【サイト名】"></dt>
　　<dd>【管理者名】</dd>
　　<dd>【サイトの説明】</dd>
</dl>

みたいのってアリでしょうか。

>>51

アリかアリじゃないか、ということではなく、私ならこうする、というだけのことだけれど。

<dl>
　<dt>
　　<ul>
　　　<li><img src="【バナー】" alt="【サイト名】"></li>
　　　<li>【管理者名】</li>
　　</ul>
　</dt>
　<dd>
　　<p>【サイトの説明】</p>
　</dd>
</dl>

>>52

dtの中身はインライン要素だけではなかったっけ？
http://www.ne.jp/asahi/minazuki/bakera/html/reference/list#dt

http://www.w3.org/TR/html401/struct/lists.html
<!ELEMENT DT - O (%inline;)* -- definition term -->
<!ELEMENT DD - O (%flow;)* -- definition description -->

>>51
私なら貴方と同じようにする。

ddって2つ続けて使えたんだ。

>>55
http://www.ne.jp/asahi/minazuki/bakera/html/book/book3
の「DD の連続は駄目だって？(p.71)」辺りを読むと吉。

>>56
サンクス

>>53
あう。指摘感謝。

☆　Webサイト制作初心者用スレッドver13　☆
http://pc.2ch.net/test/read.cgi/hp/1007538322/l50

だれかいい「Strict入門サイト」知らないか？
とりあえず「とほほは良くないらしい」というのは定着しつつあるようなんだが、
不思議マークアップなサイトを代替案に挙げられてはかなわん。
知ってるところを書いてきてくれい。

>>52
やるなら

<dl>
　<dt><img src="【バナー】" alt="【サイト名】"></dt>
　<dt>【管理者名】</dt>
　<dd>
　　<p>【サイトの説明】</p>
　</dd>
</dl>

こんな感じ。dtも連続して使えるから。前スレあたりで既出だったような。
仕様書の例は

dt-りんご
dt-apple
dd-赤い

だったっけ？

>>59
今手元にある本で調べたけど、確かにDT,DD共に1組だけじゃなくて
入れられるって書いてあった。ずっと1組だけだと思ってたよ
鬱だ。。。

＞60
漏れもだよ。
しかも、liやdt、ddも閉じてなかった・・・。
リニューアルうｐ前に知ってよかたー。

HTML 4.01 ならli/dt/ddの終了タグは省略可能だけど？？

>>59
初心者にはfontとかの物理マークアップの方が分かりやすくていいだろう。
いきなり文書型宣言だの何だの言われたら混乱するだろうし。漏れもとほほから入ったクチだしな。
まあ、「自分のはどうやら本当はあまり薦められない書き方らしい」くらいは知ってて欲しいが。

ところで、赤い事そのものに意味のある文字（色見本とか）を表示させたいなら、いっそfont color="#ff0000"で構わない気がする。
strict的にはアレだがclass="red"よりよほどマシと感じるのは漏れだけか？
どうせカラー対応視覚UA以外には無意味だし、注意書きを加えておけばアクセシビリティ問題もないだろう。

＞62
うん、正しくは省略可じゃなくて*閉じない*ものだと思ってたって事。
でも、閉じてた方が(･∀･)ｲｲ!!と、
とあるサイトで見たので（入れ子とかにする際）

>>63
＞初心者にはfontとかの物理マークアップの方が分かりやすくていいだろう

（；・∀・）それがとほほ氏の影響じゃ･･････

はっきり言ってstrictのほうが明快で簡単です。
初心者はHTML4.01strictかXHTML1.1で書きましょう。

CSSが判らなくて大丈夫。
こっちで汎用ユーザシートを用意しますから。

>>66
その汎用ユーザシートを公開してあげれば
みんな幸せになれるんじゃ。

初心者には神埼さんのところが一番わかりやすいと思う

あとは、ちゃいぱ氏のサイトも
ttp://www.parkcity.ne.jp/~chaichan/
なかなか(･∀･)ｲｲ!!

初心者は「強調したい」と思うんじゃなくて「赤くしたい」と思うのではないか?
だとしたらStrict+CSSは一端概念を抽象化しなきゃいけない分
まわりくどくてわかりにくくて受け入れられないと思う。

でも、その人創価Ｘ会・・・・

あ、そうなんだ。知らんかったよ。
創価学会は、金さえ貢げば極楽浄土ってやつでしょ？　確か。
ちゃいぱさんも報われないなぁ。

ちゃいぱは創価じゃなくて
立正佼成会だか親鸞会だか
そっち方面じゃなかったっけ？

あの人の日記見てるとﾁｮﾄ怖い。

ちゃいぱ掲示板にW3C石川ｾｿｾｲ降臨。すげぇ。

>>70
それは HTML の初心者？それとも文章を書くことの初心者？
文章を書くことに慣れているのであれば、強調するために赤くする
という考え方になる

文章を書くことの初心者であれば、まず先にそっちを勉強してこい。

>>75
文章というか、論文形態の文章に馴染んでればそうなるだろうが
文章というのはそれだけではないと思われ

「ここは赤くしたいな」「ここは青くしたいな」って思ったのを
わざわざ「ここはなぜ赤くしなければならないのか?」と考え直さなきゃいけないのは
広く大衆に普及するとは思いがたい。

>>76
小学校の作文の時間に「ここの文字を赤くしたい」とか考えたことあるか？

作文では原稿用紙の使い方──段落の初めは一文字空白にするとか、名前は下から一文字開けて書くとか、そういう「論理マークアップ」を習うだけだと思う。

書体や文字サイズの設定などは、言ってみれば本の装幀に当たる部分で、ライターの考えるべき範疇ではない。HTMLはライターが使うための言語だ。

どうでもいいけどハリーポッター読んでみると楽しいかもよ。

>>77
>作文では原稿用紙の使い方──段落の初めは一文字空白にするとか、名前は下から一文字開けて書くとか、そういう「論理マークアップ」を習うだけだと思う。
それは物理マークアップの方だと思われ。

タイトルはこういう「スタイルで」書きますよ、形式段落はこういう「スタイルで」書きますよ、というのは習ったけど、「こういう情報単位を段落といいますよ」といった事はサッパリ教えてもらわなかった気がする。

>>79
p {text-indent:1EM;}
address {margin-bottom:1EM}
と置き換えられるんじゃないか？（この場合段落＝形式段落だよな）
ちなみに漏れは上記に加え
h1 {margin-top:3EM;}
address {margin-left:1EM;}
だった。どうでもいいか。

で、「ホームページ作りたい！」とか言う奴は文章を書きたいとかそういった明確な目標を持たないでなんとなく作ってみるってのが多いと思うが。作文用紙じゃなくてむしろ「じゆうちょう」に近い気がする。
それに例えば日記ごときに論理構造を考えるのは未経験者には面倒だろう。
77のように「ライターのみの言語」と考えるならそれもアリだが。

>>79
SGMLなら書式をタグと見做すこともできるけど、それは割愛して。
段落の表現は、

　　英文なら一行開け
　　和文なら行頭一文字開け
　　HTMLなら前後を<p></p>で括る

ということになると思う。上の二つは自然言語としてのマーク付けだな。
q要素なんかも解りよい例だと思われ。

　　「和文における[引用]」
　　"英文における[引用]"
　　<q>HTMLにおける[引用]</q>

って感じね。ruby要素なんかもそうかな。

# どうでもいいが、piroﾀｿここ読んだ？　違うか？

>>77
＞HTMLはライターが使うための言語だ。

本来そうあるべきなのかもしれんが
現実は全然そうじゃないだろ。

作文の例えはナンセンス。
>>80に同意。

>>74
呼んだ?

こっちも見てます、一応。

>>83
まじっすか？　質問があるのですが、
「XHTML 2.0 ではいくつかのブロック要素が p 要素内部に認められるらしい」
って本当なのでしょうか？

>>84
本当です。少なくともリストが入るのは確実。

でも「p のネストは禁止」とか言われて DTD 書かされる身としては
頭が痛いんですが。li や dd の中に p 入っちゃうし。

>>85
なんでpのネストを禁止しちゃうの？

<p>〜に曰く、
<blockquote>
　<p>段落1</p>
　<p>段落2</p>
</blockquote>
と。</p>

なんてのは不可？　やっぱり何かしら聖域があるんですか？

>>86
>なんでpのネストを禁止しちゃうの？

文書構造として「段落」がネストするというのが気持ち悪いからでしょう。
実際のところ TREX でも使わない限り XML で exclusion 相当のことは
できないので、「直接のネストは禁止」あたりに落ち着くとは思いますが。
DocBook や XMLspec にしてもそんな感じですし。

ちなみに blockquote もおそらく入ります。div は今のところ入らない予定。

>>87
DocBookみたいにpを分裂させてしまうってことは流石にありませんよね(w
(というか、新しい要素型の追加はあるのかしらん？)

いずれにせよ、1/14には草案を出して欲しく思います。今度こそは(藁
待ち侘びておりますので、作業頑張って下さいませ。

# >>74のスレにエラッタじゃないかって質問が出ているようですが如何。
# ttp://www.parkcity.ne.jp/~chaichan/qanda/qa2342.htm?01-12-20-21-48

>>88
> DocBookみたいにpを分裂させてしまうってことは流石にありませんよね(w

それはないでしょう。

> (というか、新しい要素型の追加はあるのかしらん？)

このあたりは入るかも…。
http://www.w3.org/2001/09/21-orf/xhtml-family/slide24-0.html

> いずれにせよ、1/14には草案を出して欲しく思います。今度こそは(藁

9月にニューヨークでミーティング中に WTC に飛行機が突っ込んで
ミーティングどころでなくなってしまったのがボディブローのように
じわじわと効いているような気がする今日この頃…。

# >>74のスレにエラッタじゃないかって質問が出ているようですが如何。

後で時間があれば…。さすがに各地の掲示板なりニューズグループなりを
常時見て回って全ての質問に答える時間的余裕はないので仕様に関する
コメントは [email protected] へ、ということでひとつよしなに。

>>89
>9月にニューヨークでミーティング中に WTC に飛行機が突っ込んで
>ミーティングどころでなくなってしまった
笑えん(w そうか度重なる延期にはそんな背景があったのか。

しかしsection/hなんて要素型が定義されるのね…。
「HTMLはフラットな言語であり、階層構造を示さない」
(http://kanzaki.com/docs/html/htminfo-ex1.html#constraints)
っていう制限がやっと取っ払われるのか。
ていうか、pの中にブロックが認められる以上当然か。いずれにせよ万歳。

<div class="section">
　<h2>heading</h2>
　<p>paragraph</p>
</div>
にさよならだ。

これからは
<section>
　<h>heading</h>
　<p>paragraph</p>
</section>
の時代だ。(推測)

きっとDTD(一部展開後)はこんな感じ。
<!ENTITY % Block.mix "%List.class; | %Block.class; %Misc.class;" >
<!ELEMENT section ( (%heading.class;)?, (%Block.mix;)*, ( section | %Block.mix; )* ) >

heading.classがどうなるのかが謎だが。hのみ？　h1-h6及びh？
それともlegacy-heading.classとか作って、
section/hかsection/h1-h6かの一方を選択する形式にするのか？
激しくわくわくするのは漏れだけですか？　そうですか。

>>90

<section>
<h>h1 相当</h>
<div>
<p>...</p>
</div>
<section>
<h>h2 相当</h>
<div>
<p>...</p>
</div>
</section>
</section>

とか

階層が自動的に見出しレベルを決めることになるから
何も考えなくても済みそうで良いな

CSS のカウンタ関係との絡みは、CSS3 で解決になるのか
section > section > h { ... }; なんて振り方になると鬱

>>91
＞section > section > h { ... }; なんて振り方になると鬱

別にそんなに打つには感じないけど(w
section:nest(3) > h {..}
みたいな疑似要素ができると便利かもね。
それよりも「特定の子要素を持つ親要素」を特定するセレクタが早く欲しい。
img < p みたいな感じの。

つーか、昨日訊くの忘れたのだが、quote要素の引用符付けをどうするのかが凄く気になる…。
できれば、引用符は生テキストには書かないという現状のq要素の方針を踏襲した上で、
UAにはデフォルトでは引用符を付けさせないようにして欲しい(多分そうなるだろうけど)。
引用符を付けたい場合は常にスタイルシートで指定っていうのが一番だと思う。

b,i, big, small辺りを取っ払ったりはしないのかな……いい加減要らないと思うんだが。

>>93
順調に行けばなくなるはず。

新仕様のブラウザ実装は何年後になりますか？

>>92
＞img < p みたいな感じの。

それ禿げしく( ﾟдﾟ)ﾎｽｨ…｡

img < a{
background-color: transparent;
border: none;
}
とかできたらちょっと助かる。

＞b,i, big, small辺りを取っ払ったりはしないのかな……いい加減要らないと思うんだが。

漏れは残ってて(　ﾟдﾟ)ﾎｽｨ…

>>93
smallは名前からすると論理要素にも見えないこともないと思うのだが…。
http://www.dictionary.com/cgi-bin/dict.pl?term=small
　　　1. Being below the average in size or magnitude.
　　　2. Limited in importance or significance; trivial: a small matter.
　　（以下略）
強調の逆の意味として使えばいいんじゃん！
と思ってたら。
http://www.w3.org/TR/html401/present/graphics.html#edef-SMALL
　　　SMALL: Renders text in a "small" font.
そんなぁ……でも俺は使うぜ。人間がStrictじゃないから。(涙

>>99
それ、ﾁｮｯﾄ前に
けいﾀﾝと野嵜が論争してたﾖ

（　・∀・）ノ 確かにsmallじゃなくても強調の逆の意味を持つ要素は欲しいかも

＞101
同意。

<yawa>それはちょっと</yawa>みたいな？

<h1>Strict-HTML スレッド 2.0 <weak>(W2C Recommendation)</weak></h1>

こんなんだったら、俺も欲しいな。

FAQになりそうな予感。
Mozilla 0.9.7 リリースノートより。
---
厳格なドキュメントタイプ宣言（たとえば HTML 4.01 Strict）を使ったページが
外部スタイルシートに （<link>、@import、他を使って）リンクしていると Mozilla
は "text/css" という MIME タイプで公開され たスタイルシートだけを読み込
みます。text/plain、application/x-pointplus、そのほかの MIME タイプ で公開
されているスタイルシートは 読み込まれません。

ヤフーオークションで、幻の人気商品、発見！！！

今は無き「コピーガードキャンセラー」↓
http://page3.auctions.yahoo.co.jp/jp/auction/c14780984

ヤフーオークション内では、現在、このオークション
の話題で、持ちきりです。

>>95
ある意味すでにコアの部分は XML 対応のブラウザで動きます。
section, h, l あたりの実装には特別な処理は要らなくてただごく
基本的な CSS1 のサポートがあれば OK。半年くらい前に書いた
XLink を使ったプロトタイプは Mozilla / Netscape 6 あたりなら
xml:base 対応も含めて普通に動いてます。可能な限り XML の
標準的な機能を用いるのが XHTML 2.0 の基本コンセプトなので。

# 実際に XLink (の syntax) を用いるかどうかはいまだに検討中。

逆に言えばスタイルシートを使わないとまともな表示は期待できない
(サンプルスタイルシートは提供される予定) し、HTML ブラウザは
全く眼中にありません。素人にはお薦め出来ない。

1/14にはDTD・追加になるモジュールも公開して( ﾟдﾟ)ﾎｽｨ…｡

>>107
おお、期待 sage
HTML ブラウザ捨て捨ての方針は大歓迎

というか、話を聞けば聞くほど
W3C day の懇親会で直接話をしていたような気がする
今日この頃

＞逆に言えばスタイルシートを使わないとまともな表示は期待できない
＞(サンプルスタイルシートは提供される予定) し、HTML ブラウザは
＞全く眼中にありません。素人にはお薦め出来ない。

非常に期待

>>85
ありみかたんはどーするんだろうね。

別に常に最新の仕様を追っかけなくてもいいだろ。
普通のサイト制作なら、HTML4/Strictで十分だ。

>>110
引用文の通りだとすれば別にHTMLである必要性を感じないんだが……
XLink、CSS対応のXMLエンジンがターゲットならもっと汎用的な名前にすればいいのに。

>>113
だから XHTML
XHTML は元々 legacy な HTML は捨ての方針
XHTML/XHTML Basic/Modularization of XHTML のファミリからしたら、
XHTML 1.0 は異端

>>112
そうだよね。
別にHTML2.0で書いてたって後指さされるいわれはないし。
大事なことでした。

>>89

石川セソセイ、そこにアドレス書くのはSPAM呼び寄せてると思うんですが...

>>111
そゆのが出来るならおっけーってことで、
pの中にul入れた書き方の方が読みやすい文章になりゲなら
使うっすよ。躊躇なっしんぐ。リンキオーヘン♪

実際、small的なのが必要なときってどうしてます？
<span class="small">hoge</span> とか？

>>116
すでに死ぬほど来てるので今さら100や200 SPAM が増えたところでどうって
ことないです。仕様書や W3C の Web サイトのあちこちに書いてある以上
今さら隠しても無駄。www-html-editor の S/N 比に比べれば 2ch なんて
かわいいものです。

>>118
どの意味のsmall的?

moderate 的 small。

<small>おれのチンコ</small>

>>119
初めまして。
XHTML2.0に関して質問があります。
宜しければご教示くださいませ。宜しくなければ、いっそ氏ねと…。

【1】sectionの位置
hはsectionの子供として以外にも書ける様になるでしょうか?

例えば、
<body>
<h>h1相当</h>
<p>ほげ</p>

みたいな書式は可でしょうか?

【2】hは必須か

sectionの子供としてhは必須になりそうでしょうか?

【3】スタイルシートの指定

<?xml-stylesheet …
と
<link rel="stylesheet" …

どちらがより望ましい事になるのでしょうか? それとも、同等扱いでしょうか?

念の為補足ですが、「いっそ氏ねと」の出典は『婦系図』です。(たしか。)

>>123
漏れの予想では(聴きたくない？)

【1】body直下のみは可かもしれない。他は不可。
　　 body直下のみ可というのは、bodyを特別なsectionと見做す場合。
　　 (bodyの定義が面倒そうだ)

【2】恐らく必須にはならない。意味段落のような使い方もできないと困る。
　　 なので漏れは>>90のように予想した。
　　 でもそのあたりはdivでやれって感じもするな…。

【3】「望ましい」のは元々処理命令の方だと思うが。
　　 「処理命令を使うことにより、主たる文書構造を
　　 　アプリケーション特有の処理情報で汚染することが避けられる。」
　　 というのがxml-stylesheet処理命令の存在意義なんだし。

>>119
石川先生カッコイイ( ・∀・)

<strong>の逆の意味が使いたいときって何を使ってます？
<small>は<big>に対応するものですよね。

<strong>おれのチンコ</strong>

強調の逆（弱調？）って論理的にあり得ないような…。
音楽じゃないんだから。
マークアップしなければ済む話じゃないのかしらん。
あるいは何も書かないか。

>>129
強調の逆というか
ちょっと注意書きを書きたいときに
そういう要素が欲しくなるなぁ。

俺はよく ul, ol, dl 要素の中に
caption 要素を入れたくなるんだが、
リスト要素の表題ってどうするのがいいんだろう？

>127
<!-- -->

>>131
(・∀・)ｲｲ!

>>129
よくよく考えてみれば、なんで弱めたいのか意味を考えて、

<span class="whisper">もしもし?</span>

とかすればいいわけですしね。

>>130
たしかに...
h* 使ってるけどいいんだろうか。

>>129
俺は、>>104でも書いたように、h1要素の中に
サブタイトルみたいなのを入れるのに欲しいな＞強調の逆

<h1>スターウォーズ１<weak>ファントム・メナス</weak></h1>

<h1><weak>機動戦士</weak>ガンダム</h1>

こんな感じに使いたい。
で、次のようなCSSと組み合わせるんだ。

h1 weak{font-size:smaller;display:block;}

>>134
文字通り<subtitle>ファントム・メナス</subtitle>
が欲しい。

>>135
それはh*で表現できるんでは？

>136
h1の一部としてのサブタイトルと
子項目の見出しのh*とでは、意味が違うでしょう。

b要素はヤメてemの方がいいっすかね？
それともstrongかなぁ？

でも、b要素もstrictだし・・・悩む・・・。

"h1の一部としての"サブタイトル≠<subtitle>

"h1の一部としての"がついてる時点で限定性があってダメ

>>130
HTML3.0にはlh要素(リスト見出し)があったが、草案で破棄された。
多分定義リストとしてマークアップするべきなのだと思う。

<ul>
　<lh>2ch</lh>
　<li>WEB管理制作</li>
　<li>ラウンジ</li>
　<li>ほのぼの</li>
</ul>

じゃなく、

<dl>
　<dt>2ch</dt>
　<dd>WEB管理制作</dd>
　<dd>ラウンジ</dd>
　<dd>ほのぼの</dd>
</dl>

ってこと。

>>138
em は強調。
strong は「より強い」強調。
b は太字。

>>139

<h1>ウェブ・ユーザビリチ<subtitle>〜顧客を逃がさないほげほげ</subtitle></h1>
<h2>目次</h2>
<h2>第1章</h2>

こういう場合についての話をしているものとばかり思ってたのですが。
h*で代用するというのは

<h1>ウェブ・ユーザビリチ</h1>
<h2>〜顧客を逃がさないほげほげ</h2>
<h3>目次</h3>
<h3>第1章</h3>

こういう事だと思うのですが、これは、内容からするとおかしいでしょう。

＞141
はう！（；´Д｀）
そうでした・・・逝ってきます。

あ。別に<subtitle>限定でそういう要素が欲しいということではなく、
「強調の逆」の要素の使い方の一例ということです。

連続ですみません。

<h1>ウェブ・ユーザビリチ</h1>
<subtitle>〜顧客を逃がさないほげほげ</subtitle>

確かにこういうのもアリだと思います。
でもh*で代用はできないです。

>>133
classで意味付けするの？
その理屈だと、
<em>ゴルァ！！</em>
より
<span class="emphasis">ゴルァ！！</span>
ってことに。


ちなみに。
>>130 >>133
captionの存在の方がむしろ必然性を感じられない。
title属性じゃ、ダメなのだろうか・・・？

ん〜。ちょっとおかしかった。
>>146のは、

<span class="angry">ゴルァ！！</span>
ってことに。

の間違い。


>>142
>>139が言いたかったのは、
「そんなもんh?の中でしか使えねぇじゃねぇか」
ってことでは？

もうちょっと説得力のある質問をしないと石川セソセイが降りてきてくれません。
みんなで頑張りましょう。

>>148
回答を期待しちゃ駄目だよ(w

<h1 title="〜ほげほげ〜">（・∀・∀・）ﾇｯﾍｯﾎｰ</h1>

h1:after{
content: attr(title);
}
　↓

（・∀・∀・）ﾇｯﾍｯﾎｰ 〜ほげほげ〜

しかしなんだ、上から見てきて思うのは、
タイトルってのは見出しとは違うんじゃないかってことなんだが…。

<h*>の順番を一個飛ばすとlintに注意されるので、飛ばす場合は

<div class="none"><h*>飛ばされる</h*></div>
（.none{display: none;}）

としているんだが、他の人はどうか。
見出しを飛ばせると結構自由なことが出来る（と思うのは漏れだけだろうか）

>>152
本末転倒甚だしすぎます。lintに注意されるので……
とか言ってるようではstrictを語る資格ないよ。

少なくともその「自由なこと」とは何なのか述べましょう。

見出しを属性としてマークアップってのは奇異な感じがするんだが。

>>152
笑える。見出しの意味を学んでこい。

>>152
激しくワラタ(w

「targetの代替は？」とか言い出す奴は良くいるが、
まさか見出しレベルの注意でごねるとは…。

>>152
そもそも,見出しを飛ばす必要性がわからん。

>>146
でも、正直現在存在する要素だけじゃ完全な意味付けは無理じゃない？
みんな <div class="section">...</div> 使ってるみたいに。

なんか、

物理マークアップ: b i
文章構造マークアップ: em strong h1 p
意味マークアップ: var code kbd

ってかんじに分かれて、
かつ、意味マークアップは圧倒的に表現力不足ってかんじ。

以前、どっかのサイトのソースみたら

<H1>ほげほげ<SUB>さぶほげ</SUB></H1>

って、してたよ。
これってどうよ？

ちなみに「さぶほげ」と書いたのは
サブタイトルってとこからきてる。
SUBとは関係なし。

ま、例文だからいいけど

強調って言うのはある意味相対的なものだから、
逆に、メインタイトルの方をstrongにしたら？
普通の見出しとサブタイトル、って言う
文章構造から外れる感じがするけど。

>逆に、メインタイトルの方をstrongにしたら？

今現在は、おっしゃる通りの方法を使ってます。

●理想（要望）
　<h1>スターウォーズ１<weak>ファントム・メナス</weak></h1>

●現状
　<h1><strong>スターウォーズ１</strong>ファントム・メナス</h1>

でも、メインタイトルとサブタイトルですよね？
サブタイトルの方が、下位というか、補助的な意味合いではありませんか？

始めにメインタイトルありきで、その補助的な意味でサブタイトルがあるのだと私は思います。

とすれば、最上位の見出し（h1）の一部を強調（strong または em）してメインタイトルとするよりも、
最上位の見出し（h1）の一部を弱めてサブタイトルとした方が理にかなっているのではないでしょうか？
考えすぎかなぁ……。

>>162
突如思いつきましたが、
<h1><ruby><rb>スターウォーズ</rb><rp>〜</rp><rt>ファントム・メナス</rt><rp>〜</rp></ruby></h1>
というのはダメでしょうか?

ルビが必ずしも読み仮名でなければならない訳でも無いので、
まずまず良いのではなかろうか、と。

>>125
ありがとう（・∀・） 参考にﾅﾀﾖ

>>162
うん。だから自分も気持ち悪いと思うよ。

飛ばす必要性の説明にかけていたようだ。

たとえば下のような構造の文章

タイトル
　（本文）
　　サブタイトル
　　　段落
　　サブタイトル
　　　段落
　関連リンク
　　関連リンク1
　　関連リンク2

の場合、「（本文）」がh2に相当するが、わざわざ本文と書くのはどうかと思ったので飛ばしている。
つまり、構造上は存在するが実際には書かないとき。

>>165
うーん？
いまひとつ理解りません。

>>166
「構造上は存在するが実際には書かないとき。」だけ理解してもらえばいいです。

なるほど、「（本文）」が無い状態で見出しレベルを飛ばさずやってしまうと
「サブタイトル」と「関連リンク」が同じレベルになってしまう、
或は「タイトル」と「関連リンク」が同じレベルになるのが困る訳か。
俺も似た様な事で困った経験があるよ。
もしレベルとして問題無いマークアップならその警告を無視してやるか、
（Another HTML-lintでも宗教的な問題に分類されてるでしょ？）
どうしても構造を明示したいならdivで括ってやるか。
そう言う意味ではXHTML2のsectionは早く使いたいな。

>>168
理解してくれてありがとうございます。
これで名誉挽回だ。ふぅ。

　　　　　　　 -=-::.
　　／　　　　　　　＼:＼
　 .|　　　　　　　　　　ﾐ:::|
　ﾐ|_≡=､´ ｀, ≡=_、　|;/
　 ||..◎ .|￣|. ◎　|─/ヽ
　 |ヽ二/　　＼二/　　∂>　　／￣￣￣￣￣￣￣￣
　/.　 ハ - −ハ　　　|_/　＜　StrictHTMLなんてキンマンコ！！
　|　 ヽ／ヽ／＼_ノ　 / |　　　＼＿＿＿＿＿＿＿＿
.　＼､ ヽ二二／ヽ　 / /
.　　 ＼i ＿＿＿ ／_／

>>165
んーでも、そこまでこだわるなら「(本文)」に相当する見出しを
(display:none;でなく)きちんと書くべきだと思うけど。

>>171
ていうか、divで囲む理由にはなってないよね。
見せたくないなら、
<h2 class="main">本文</h2>
.main { display: none; }
でいいじゃんか。

>>171
そうですかねえ…。
本文の前に「本文」と書いている前例を一度も見たことがないんで。
俺は小泉孝太郎じゃないので、前例がないと不安です。

>>172
過去ログ読んでね

>>172
失礼しました。
ちゃんと文を読んでいないのは漏れでした。
赤っ恥。

第一、CSSの話はこのスレには関係ないし。

>>176
CSSじゃなくて、文章の構造を明記すべきかどうかという議論じゃないの…？

>>177
こういう場合は、一般の書物などを見ると、
h1 とほぼ同内容のことが h2 にも書かれてる感じ。

>>165
h2に相当するのが「本文」以外にあり得ないのか、
例えば「タイトル」を持ってくることはできないか、
h1として相応しい見出しが他にないかとか、考えられない？

何にしても消すことを前提に書くのはおかしいと思う。

>>179
その文書を自分の権利で改変できる場合はそれでもいいけど、
与えられた原文をマークアップするような場合だと、結構悩む…。

.main { display: none; }

メインなのに見せないのかよ・・・

素朴にﾜﾗﾀ。

>>179
消すことが前提じゃなくて、後から考えたら消すのが自然だからそうしたまで。
あと、消すことはなぜおかしなことでしょう？

>>183
単純な疑問

CSS が適用されていない場合にも、その表示は自然なの?

自然ではないのであれば、それはやはり構造がおかしいのだろうし、
自然なのであれば、それはそもそも消す必要がないと思われ

"戻る" リンクって構造的にどこに含めるべきでしょう？

単体ならdivかp
ってそういうことじゃないか。
折れは大体、h1の直後だけど。

＞185
ページの上下にあれば(･∀･)ｲｲ!!と思われ

>>185

文書構造上は不要じゃないかね？
WWW UAが勝手にやれば良いこと。実際やってるし。

文書構造上、すべてを1ページで済ますべきだろうねえ

>>188
そういうのは、link 要素とかで済ませるべきってことでしょうね。

IE がちゃんと link 要素認識してくれりゃあなあ。
プラグインかなにかで認識できるようにならんかなぁ...

http://ton.2ch.net/test/read.cgi/gline/1000370756/12

>>158
＞完全な意味付け
をする必要性、意味は？
そんなことをするならHTMLより、それこそXMLの方が。

>>185
JavaScriptでその文字を生成するなら、何処でもいいと思う。
<a href="JavaScript:〜">戻る</a>とHTML中に書くのは
既に環境依存だと(たぶん)思うし、構造として必要とも思えないので、
どことかいう問題ではないと思う。

>>184
構造としては正しいが、表示としてはおかしいことは認めます。
しかし、表示の仕方を決めるのがCSSの役目であって、「消す」ということもCSSの役割の一つでは？

>>192
うーん、code とか var って文章構造じゃなくて意味構造だと思うんだけど。
HTML の守備範囲って文章構造までだったら、code なんていらないような。

>>185
そっから関連して。
サイトナビゲーションみたいなものはどこに置くべき？

| top | information | updatelog |

みたいなの。

こういうのも link 要素にまかせて body 以下には置くべきでない？

「戻る」って表現が良くないよな。

たとえば
<a href="contents.html">内容一覧</a>
みたいなリンクなら、文書としても不自然ではない。

ついでにCSSで↓のようにしておけば
印刷時の利用性も高まる。

@media print{
a:after{
content:"[" attr(href) "]";
}}

>>195
文章の内容とは直接関係ないから
h1の前と、本文のあとに入れてる。
＃個人的にはリストでマークアプした方がいいと思うけどね。

>>196
＞「戻る」って表現が良くないよな。
同意。
どっかの本に「戻る」「BACK」「TOP」などは紛らわしいので使うな、と書いてあった。

>>198
うーむ。そうなると、
サイトのトップはどう表現するべきでしょう...

back は単に戻るべき場所のタイトルでも入れとけばいいだろうけど。

>>199
HTMLのリンクタイプを参考にしてみては。

野崎タンのサイトのようなナビゲーションはどうなの？

>>201
ときどき見るんですけど、野崎タンのサイトはどこにあるんでしょう。

>>202
W3Cです。

>>199
サイトのTOPはHOME。これ最強。
TOPだけだと、ページの一番上と勘違いする人が多々いる。

>>204
いわゆるHPですか。

link type から言えば、「スタート」じゃないの？

ページの一番上は「 PAGE TOP 」で
一番最初のページは「 TOP PAGE 」。

…ダメですか。

スレ違いかもしれませんが初心者スレで弾かれたのでここで聞きます。
XHTML1.1でFlashを表示させたいのですが
<embed>を使うとHTML-lintではMozilla用のタグでエラーになってしまいます。
しかし、それを削除するとIEでは表示できてもNN6（又はmozilla）では表示できません。

また<object>には等価な内容を記述する、とエラーがでましたが具体的にはなにを記述すれば良いのでしょう？
質問ばかりですいません。

>>207
で、今までに何と何を調べてきましたか？

>>202
「野嵜」「言葉言葉言葉」で検索しよう。

>>207
Flashが見れない環境への配慮。
Flashの代わりとなる情報を記述する。

>>205
link type の start はプレゼンテーションの始点では
W3C の Spec. では cover.html がこれに相当

link type の top がサイトトップでは

>>210
Link typesにTopなんて無いんですが……Mozillaの独自拡張では？
http://www.w3.org/TR/1999/REC-html401-19991224/types.html#h-6.12

>>211
Mozilla の対応は既存の文書への配慮かと。
HTML3.2 に top の記述があるようだし。
http://www.w3.org/TR/REC-html32.html#link

>>212
ありゃ、HTML 3.2が出典でしたか。ｽﾐﾏｾﾝ。

>>210
＞link type の top がサイトトップでは
サイトトップという観念に囚われてる時点で既に間違いでは？
「トップ」を決めることにあまり意味は無い気がする。
文章群の最初のページならStartとか、
目次があるページなのならContentとか。
その、トップページの役割によるかと。

ま、意味が通じればいいと思うけどね。

Top of this pageとTop of this siteが一番誤解がないと思われ

うーん、link 要素って自分で勝手に作っちゃだめなんですか？

>>216
存在している要素を新しく定義し直したいのか？
多分君が言いたいのはリンクタイプだろうな。仕様書を読め。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/types.html#type-links
リンクタイプを定義する標準的なプロファイルフォーマットは存在しないし、
何らかのプライベートなプロファイルを読む様なブラウザも存在しない。
事実上無法地帯だと思っていいよ。

ナビゲーションバーもどきを作るって意味ではなく？

質問です。
なぜscript要素はインラインなのに、noscriptはブロック要素なんですか？
Transitionalではnoscript直下の子要素はインラインでも包含可みたいですが。

例を出せば――

<p>このリファラーの取れるカウンター（
<script>
<!--
document.write("<img src='〜.cgi' width='50' height='10' alt=''>");
// -->
</script>
<noscript><img src='〜' width='50' height='10' alt=''></noscript>
）は○×さんの作品です。</p>

この場合、<noscript><p><img></p></noscript>にしなければいけないってのは
納得ゆかないんですが。

>>219
scriptはbody,blockquote, formの直下にも置けるよ。

>>220
いえ、scriptでなくてnoscript（の中身）を問題にしてるんですが。

>>220
scriptやnoscriptがちょっと特殊だからDTDで表現しきれていないんじゃないかな。
XHTMLでのinsやdelも妙な形になってるし、俺は未完成だからって事で我慢している。

ああ、なるほど。スマソ
noscriptをインラインにすると、noscriptの中にブロック要素を
置けなくなってしまい、必ず<p><noscript></noscript></p>の
ように書かなきゃならなくなるから。
かな。

http://tohoho.wakusei.ne.jp/html/noscript.htm によれば――
<NOSCRIPT>
包含可能要素 ブロック要素 / インライン要素
（HTML4.01Strictの場合はブロック要素のみ）

StrictとTransitionalで異なる理由がよくわからない……。

確かにimgのalt属性のような感覚では使えないね。

ところでnoscriptってブロックレベル？
内容モデルがインライン不可だから事実上はそうなるけど。

>>225
>内容モデルがインライン不可
つまり、
<p>〜<noscript><img src="" alt=""></noscript>〜</p>
は不可で
<p>〜<noscript><p><img src="" alt=""></p></noscript>〜</p>
にせよってことですよね？
なんか変ではありませんか。
私がよく理解してないのかもしれませんが……。

>>219
document.writeでpタグごと吐けば？

>>226
代替として使うことを考えると確かに変かなと思う。

実際問題、p要素内にnoscriptは書けないから、
>>227の言うようにp要素ごと出力して、

<noscript>
<p>このリファラーの取れるカウンター（<img src〜>）は○×さんの作品です。</p>
</noscript>

とするのがベターではないかと。

>>227
それは結局、HTML4.01Strictにおいては、script要素（とnoscript要素）をインラインで使ってはならないってことになりますか。
ブロック要素として記述せよ、と。
でもインライン要素だけでなくそれを含むブロックまでdocument.writeで
書き出すべしとなると、場合によってはスクリプト依存度が高過ぎて出力に
時間がかかりますよね。
どうも釈然としないので、TransitionalからStrictへの移行は見送っておきます。

＞BODY直下は、ブロック要素またはSCRIPTが一つ以上
http://east.portland.ne.jp/~sigekazu/html/html401.htm

これって嘘？　>>219は仕様書読んだ上の主張？

>>230
確かにscript要素はbody直下やインラインとしても書けるみたいですが、
その代替とするnoscript要素がブロックとしてしか利用できないので、
結局script要素もブロックとしての使用せざるを得なくなるってのが
>>229で述べたかったことです。
誤解があったらご指摘下さい。

べつに、scriptとnoscriptをセットで使わないかんということはないんだし。
もっと柔軟に考えましょうや。

>>232
でもdocyment.writeを使ってる場合はやはりnoscriptが要るでしょ？
それに、そもそもStrict(厳格)である故に柔軟にはなれないわけです。

これのどこに問題があるわけ？

<body>

<script type="text/javascript">
document.write("<p>〜</p>");
</script>
<noscript><p>〜</p></noscript>

</body>

えーとだな、そもそもHTMLのDTDにとっては、document.writeが吐き出すものは
何でもいいのである。HTMLとJavaScriptは、まったく別物だから。HTMLは
document.writeを定義しているわけではない。

次のような記述は、HTML的には正しいのである。
<span><script>document.write("<p></p>");</script></span>

document.writeが生成するものは、UAに依存するものであり、
HTMLの守備範囲ではない。UAと筆者の解釈にまかされる。

>>234
一例として、パラグラフ中の一語句だけをブラウザ判別によって
異なる表示にしたい場合。

<p><dfn>ブラウザ</dfn>とは〜〜〜〜。<dfn><acronym>UA</acronym></dfn>とは〜〜〜〜。
<script><!-- 〜〜〜document.write("あなたがご覧のUAならば〜です。")//--></script>
つまり〜〜〜〜説明続く〜〜〜〜。</p>

JavaScriptによって表示を異ならせたいのは一部分に過ぎないのに、
パラグラフの前後を含めてdocument.writeで吐き出させねばならないってのは
非効率的です。パラグラフが長文ならば猶のこと。

>>236
でもそうしないとstrictでは書けないんだからしょうがない。
transitionalで我慢するしかないんじゃ。

関係ないけど「UA」はabbrじゃない？

document.writeってのは、strictなHTMLなんて誰も気にしていなかった
時代に作られたもので、過去の遺物です。
DOMを使えば問題なし。

<p>
ああああ
<span id="hoge">いいいい</span>
うううう
</p>
<script>
o = document.getElementById("hoge");
o.childNodes[0].nodeValue = "ええええ";
</script>

>>238
DOMはよく知らないんだが、その場合、noscriptがどう記述すればいいんかね？

>>234
見つけたぜクソやろーーーーーーーーーーーーーー！！
ここで会ったが百年目！！死っねーーーーーーーーーーー！！！！
ぶっ殺ーーーーーーーーーーーーーーーーす！！！！

>>238-239
詮ずる所、scriptよりもnoscriptの融通の利かなさが問題なんだから、
DOMにしたっておんなじことではないのかな。
noscriptがdelやinsみたいにブロックにもインラインにもなればよかったのにね。

>>240
社会でちゃんと暮らせるようにお勉強してくれません？
駄レスしかできないならこちらへ
http://tmp.2ch.net/kitchen/

結局noscriptの中身が「ブロックもインラインも」じゃなくて
「ブロックだけしか許さん」な理由って何なんだよｳﾜｧｧﾝ!ヽ(`Д´)ﾉ

俺も>>236と似たような理由で前から不便に思いつつしぶしぶ
<noscript><div>インラインな中身</div></noscript>
ってしてた。

>>235(>>220)
仕様も読もう。
>HTML文書は、どのSCRIPT要素の処理前も処理後も、HTML DTDに適合するよう制約される。
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/interact/scripts.html#h-18.2.4

なので、
><span><script>document.write("<p></p>");</script></span>
はやはり不正です。

>>219
一つ。scriptが吐くコードは本来存在しない。
スクリプトに対応さえしていれば処理後は存在するが、
HTMLの本質的（Strict的）には存在しないはず。
つまり、HTMLの守備範囲ではない。
例え外部ファイルでなく直接HTMLに書いても、
それは普通の文章的扱ではなく、%Scriptになる。
つまり、内容（文章）を含まないのでブロックレベルにはできない。
# 「内容を含んでない〜要素があります」ってlintで怒られたことありませんか？
よって、script自身はインラインレベルとなる。

二つ。noscript要素がインラインレベルを包含できてしまえば
そのnoscript要素を包含するp要素等が「絶対」に必要になる。
なぜかと言うと、noscriptはブロックレベルだが
段落等を示すものではないので必ずどこかに
p要素等（構造的に意味を成す要素）が
出現しなくてはならなくなってしまう。
分かりやすく言うと、noscriptは、構造的には
「スクリプトの替わりですよ」としか言わない。
つまり、「ここは段落ですよ」とは言ってくれないということ。
ところが、pはブロックを包含できない。
それに。>>244を考慮すると、noscript自体についてはブロックレベル
にしないと融通が利かなくなることがあるとも予想できる。
# 逆にp要素などをscript要素で吐き出し「たい」時もあるだろうし。

よって、strict的には必然。

・・・と勝手に予想してみる。

そして>>235 >>244。
レンダリング後を考えればそれも必然な気がする。
結果だけ見れば構造的に（内容の）無い要素が
ひとつ存在してしまうことになるのだから。
内容の無い要素なら、その要素そのものをなくせと言う話になる。
# Strict的な思考回になってたら自然と違和感を感じると思う。

レンダリング前の元のHTMLとレンダリング後の、
（普通に）判読可能なHTMLの両方を気にしなければ
真のstrictではないということを暗に・・・（以下略

あと、strictは必ずしも機能性や効率性のために
存在しているのではないと思う。あくまでも自分的にはだが、
非環境依存を維持しつつ、その守備範囲を（今ならXMLの方に）
広げるのにstrictの意義みたいなものを感じますが何か？

>>245
失礼ながら、長文の割には一向に説得力が無いと感じます。
>それに。>>244を考慮すると、noscript自体についてはブロックレベル
>にしないと融通が利かなくなることがあるとも予想できる。
逆に、インラインにしないと融通が利かなくなることもあるわけです。
だから、noscriptをDELやINS要素みたいにブロックにもインラインにもなり得るものと
しておけば済む話ではありませんか。
実際、Transitionalではnoscript直下がインラインでも可です。
なぜStrictでは殊更にブロックのみとするのか？　その必然性は？
……釈然としないままです。

>>242
常軌を逸してんのはお前だ！！たーーーーーーこ！！
いちいちいちいちあんなうぜえ書き込みしやがってよーーー
なんであんなうざい書き込みすんのかさっぱり意味わかんねえよ！！
おまえみたいな意地悪なヤツはマジこの世から消えた方がいいぜ！！
じゃあな！！もう二度と来んなよ！！

>>219
XHTML 1.1 では script/noscript 要素の置ける位置の違いは
script 要素が head/pre 要素に含められるというだけで、
後は %Script.class; として同列で扱われている

%Script.class; は %Misc.class; に入っているし、
%Misc.class; は %Inline.mix;、%Block.mix;、%Flow.mix; などに含まれていて、
ほとんどどこにでも置ける

つまり、script/noscript 要素は、共に text/block level で利用可能

現行バージョンの Strict な HTML といったら XHTML 1.1 なのだから、
>>219 は XHTML 1.1 使ったら?

>>248
あのう。
問題になってるのはnoscriptがどーしてブロック要素しか包含できないのかという点なんですけど。

>>246
「融通」といったのはこういうこと。

例えば、<p><span>hoge</span>foo</p>というような感じの
構造の文章をscript, noscriptで表現しようとする。
↓
noscriptがインラインを包含できてしまうと、
<noscript><span>hoge</span>foo</noscript>
と言うのが成立するが、コレだけは
構造的におかしい。段落がない。
↓
というわけで、どこかにpを入れなければならない。
1.
<noscript><p><span>hoge</span>foo</p></noscript>
2.
<p><noscript><span>hoge</span>foo</noscript></p>
のどちらかを選ぶことになるが、
pはブロックレベルを包含できないので2.は却下。
必然。
↓
じゃあ、noscriptをインラインレベルにすれば
いいじゃないかという意見もあるかもしれないが、
「スクリプト処理後」を考えると
<script type="text/javascript">
document.write("<p>〜</p>");
</script>
というようにscriptの出力にブロックレベルが
存在する場合もあり得るので「融通」と言ったまで。
この場合、
<noscript><p>〜</p></noscript>

勿論、Strict的にスクリプトで（特にブロックレベル）要素を
生成するのがよろしくないのならこの融通は無力だが、
どうなんだろう？

＞なぜStrictでは殊更にブロックのみとするのか？　その必然性は？
ということで、Transitionalでnoscriptがインラインレベルを
包含可なのはbody直下にも置けるからかと。

>>249
おっと失礼

だったら >>227 >>234 の意見で何の不満が?

XHTML 1.1 で xhtml-script-1.mod だけを overwrite して
%noscript.content; を ( %Flow.mix; )+ に書き換えてやるのも手

script 要素で気になるくらい重くなる程大量の text level 要素を
一括出力する必要があるとしたら、
ほぼ間違いなく大量の無駄があるか、文書構成に無理がある

多分文書設計をやり直した方がいい

>>238 が挙げているのはスクリプトが動作しなければ既に書かれている
元の文書が noscript の役目を果たしているので
script 要素自体 text level で書く必要もないし、noscript も要らない

私は script 要素自体が出現する必要性も認めないので
実行したいスクリプトは link 要素で読み込んでイベントで処理
>>238 の様な場合は onload で処理させる

もっとも、client side で処理させたくないから
SSI で処理させるだろうけどね

例えば <h1> は見出し、 <p> は段落、のように定義されてるけど
ここでちょっとつっこんで
<h1 class="SiteTitle"> はサイトの名前、
<h1 class="ContentTitle"> はコンテンツの名前、
みたいな共通の規格を作っておいて、
この規格に準じたサイトの同盟みたいなのを作って、
さらにこれに対応したユーザースタイルシートとか作って
配布とかしてみたりするといろいろ楽しいんじゃないか、と
徹夜明けのアタマで考えてみたり。
どうだろう。

>>252
それは、素直に XML でやってみたいね。
DTD 作るの。

ところで、<div class="section">... みたいな、
普通の要素に昇格して欲しい! みたいな良く使うクラス名ってどんなのあります？

強調の逆。
今はとりあえず small とか使ってるけど
なんか違うんだよなー、と思う日々。

日本人的なのかもな＜強調の逆

>>255
<wabi>侘び</wabi>
<sabi>寂び</sabi>

>>255
日本人的なのを忘れちゃいかんと思うんだけど。
右とか左じゃないですよ。

>>253
鳩丸でやってるような、「良い例」「悪い例」の区別とか。

<bad-samp><pre>
(間違ったコードの例)
</pre></bad-samp>

みたいな感じね。

というか、「例」を示す要素があってもいいかなと思う。

# かつてのxmp要素の意味ではないよ。念のため。

>>253
>>89 xhtml-family

いや、おれが言いたいのは
だから用意されてないんだろうってこと
否定はしないよ
sageだって日本人的かもしれん

＞sageだって日本人的かもしれん
確かに(w 最近訳もなく下げてしまう気がする。

技術系スレに限ってsage進行だよな。
雑談agaりまくり。

>>252
確か、div class="なんたら"をヘッドラインとして定義する
プロファイルがあったよ。
昔メタデータの勉強で検索して見つけたんだけど、今みつかんない（泣）

しかし、鳩丸とか見てから普通のサイト見てると、
理想と現実の隔たりをぴこーんと感じるよ。

ins/del 要素ってどういう基準で使ってます？
更新した部分全部に使ってる？
それと、一旦使ったら最後まで残してます？

普通だと明示的に更新したって部分だけに使うべきか。
typo 直しただけで ins/del するのもあほらしいよね...

<h1>最初のドキュソ</h1>
<p>それは始まった</p>
<ins datetime="2001-11-11T20:11:09+09:00">
<h1>次のドキュソ</h1>
<p>まだまだ続くぞ</p>
</ins>
<ins datetime="2001-12-02T09:00:29+09:00">
<h1>ドキュソ再び</h1>
<del datetime="2002-01-09T10:48:01+09:00"><p>そろそろ疲れた</p></del>
<ins datetime="2002-01-09T10:48:01+09:00"><p>まだまだがんばるなりー</p></ins>
</ins>

厳密にいくなら、最初の body 以下は全部 ins 要素の下に置くのだろうか...

間違った要素名を del するにはどうしたらいいんだろう。

<dvi class="note">ほげー</div>
↓
<del><dvi class="note">ほげー</div></del>
<ins><div class="note">ほげー</div></ins>

変だ....

訳注とか脚注とか、注釈のための要素が欲しい…

>>265
うまく言えないんだけど、「更新」と「訂正」は違うんじゃないかな、とか。

自分はだから

<del>WinXP 導入のメリットなんざゼロだゼロ。</del>
<ins>なんか起動とかは速くなるみたいですね。よって訂正。</ins>

とかこーゆーカンジの使い方してる。

ところで del や ins ってブロックでもインラインでも可だから

<del>
<p>この段落は無かったことに。</p>
</del>

みたいなのも可ですよね。
ところがこれだと Opera のユーザーモードで打ち消し線が引かれないんですが、
(制作者モードだととくに CSS 設定しなくても引かれる。
　あと

　<p><del>この部分も無かったことに。</del>それはそれとして…</p>

　でもちゃんと引かれる)
これは Opera のバグで良いのでしょーか。
Opera スレに書き込むべきかな。

>>267
訂正の為に使っているってことですね。
成程。
更新情報を残すっていうより、訂正情報を残すって考えれば
なんとなく使いかたが掴めてきたかも。
cite 属性なんかが生きてきますな。

>>267
><del>
><p>この段落は無かったことに。</p>
></del>

ISO-HTMLでは不可。

＞これでも、『２ちゃんねる』を誹謗中傷とゴミ情報しかない internet の掃き溜めといいます
か？　と問われれば、僕は Yes と答えますねえ。その人が仮に正装で来ていても、その場
所は掃き溜めであることに変わりはないので。

もう一方の雄（何）のお言葉。

自分的には匿名性や速報性は（率は低くとも）有益な情報を収集・提供
するうえで大きな武器だと思うけど、読んでて誹謗中傷とゴミ情報「しか」
目に映らないんではそういう感想も致し方なしか。

IEにCSS切り替えとLINK要素によるナビゲーション機能を追加する「ス切リボ」
ttp://www.xinada.ne.jp/~handa/tech/CSS/SuKiBo/
なんつーのがあるらしいYO

>270
9割とかじゃあなく、10割がゴミなんですよ。
そのゴミをいかにリサイクルするか。そういうことです。

>>272
10割か?

>>272はふしあなさん

あの<kbd>の使い方って

<p>tar.gzファイルの展開は以下のコマンドを入力してください。(linux)</p>
<kbd>tar xzvf package-name.tar.gz</kbd>

って感じで良いんでしょうか？
それとも全くの勘違い？

>>275
思想はそれでいいけど、KBD要素はインラインだよ。

<p>tar.gzファイルの展開は以下のコマンドを入力してください。(linux)</p>
<p><kbd>tar xzvf package-name.tar.gz</kbd></p>

あ、インライン…そうですね。
ありがとーです。

StrictなHTML吐き出してくれる掲示板CGIを探しています。
自分で改変してやろうとしてるのですが、クソめんどうなので。

・・・スレ違い（いや、むしろ板違い）？

http://fantasien.cup.com/perl5/
有名Strict掲示板。

あとはスキン対応の掲示板でも使えば？
ttp://www.2apes.com/
ttp://www.imaginet.ne.jp/~nobu/
ttp://www.azworks.org/~az/

>>278
ttp://www.2apes.com/products/
にあるapeboardはHTMLテンプレートを元に出力するから
元となるHTMLをStrictで書けばいけると思う。

ちなみに俺自身も同じような仕組みで
StrictなHTMLを吐く掲示板スクリプトを作ってるのだが
完成度がイマイチなので公開してなかったりする。

>>279
ありがとうございます。
前スレでpicoBBSというのも見つけました。以前に話題に出ていたのですね。失礼しました。

ところで、ElvenBBSにしろpicoBBSにしろ、なぜ投稿フォームはTABLEで組んであるのでしょう？
自分で改造しようとしたときは、

<dl>
　<dt>名前：</dt>
　　<dd>ほげほげ</dd>
　<dt>メール：</dt>
　　<dd>[email protected]</dd>
　<dt>タイトル</dt>
　　<dd>こんにちは</dd>
　<dt>コメント：</dt>
　　<dd>ごきげんいかが</dd>
</dl>

って感じで考えていたのですが。

あ、>>280さんもありがとうございます。
確かにSkinを使う形式なら柔軟にできますね。
ただ、apeboardは1年位前に使ってはみたのですが、なんか重かったので
やめてしまいました。

いろいろ試行錯誤してみます。

>>279
Elvenは形式的にはStrictだけど、思想的にはStrictっぽくないような……。
#<br>連打の箇所があったり、tableにsummaryが無かったりとか。

とか言いつつ、ElvenBBSをXHTML 1.1に改造している私がいる（爆）。
要素型名も属性名も大文字だから直すのが大変……何で小文字にしてくれなかったの（泣）。

a href="mailto:[email protected]?subject=test&body=test1test2
ってのがあって、リンクをクリックしたらメールの題名と本文をあらかじめ
入力してある状態にしたいのですが、本文のところのtest1とtest2の間に
改行を入れることができないんです！メーラーが立ち上がって本文が

test1
test2

って言う風にするにはどうしたらいいですか？
いろいろ探したんですけど、無理なんですかねえ？
どなたかご存知ありませんか？

>>284
%0A とかじゃなかったっけ？

>>284はマルチポスト。初心者スレで解決済み。

前スレ　http://pc.2ch.net/test/read.cgi/hp/992708594/352-359
＞http://pc.2ch.net/test/read.cgi/hp/992708594/365
も引用してる仕様書の例は、
dt,ddは連続してるけど「複数の用語と記述とを組み合わせる」もので
やっぱりdt,ddは一つずつで組としてるものと思える。

>>271
linkをもっとみんな書いてくれれば便利なんだろうけどな。
現状で代替スタイルシートはMoz向けの作りの奴が多いし。

Opera使いとしてはOperaがlink辿りとか代替スタイルシートに対応してないのが鬱。

Moz向けなんじゃなくて、まともにCSSに対応してるのがMozくらいしかないということで。
そこはどうかご承知下さい。

>>248
近藤って人でしたか。
http://www.alib.jp/diary/diary_200201.html#diary_20020108b
>そういう矛盾は他にもあるけど、XHTML 1.1 使って script モジュールを上書き
>定義して %noscript.content; を %Flow.mix; にしたらいいだけだろうに。

あのね、近藤さんや。
「だけだろうに」って、みんながみんなあなたみたいな技術屋さんではないんですよ。
モジュールだのＤＴＤだの素人がいちいちそんなもんいぢれるわけないでしょや。
なるべくいぢらんでも済む用に基本設定しといてくれんといけんのではないのかな。
だいたいXHTMLって次々バージョン・アップするから、逐一フォローしてられんのですよ。
素人としては、XHTMLがHTML4.01位に安定したら採用を検討してみますわ。

>>290
ま、でもここで愚痴っても何もならんわな。
仕様策定中に W3C に意見しろや。

>>290

おのれの厨ぶりを八つ当たりでごまかすなYO！
近藤氏がいたMLでも似たようなことあったな。。。

>>291
禿同。

>>291
映画監督が気に入らない批評されたら「ならお前が映画作ってみろ」と開き直る如し。
一般観客の声を蔑ろにしてはいけませんな。

>293
見てるだけで満足ならStrict極めようと考えるな。

>287
使いよう。

>>294
ん？　「見てるだけで満足」だったらそもそも批評は出てこないだろ。
やってみて不満だからこそ文句や愚痴も生じるわけで。
それともまさか、Strict志願の人はみなＷ３Ｃの策定に関与せなあかんのけ。

>295
ここの>1を見習え。
ttp://pc.2ch.net/test/read.cgi/hp/1006224399/
あとさとみかんをチェックすれ。

そもそも>>219は、noscriptがブロックボックスしか持てないのが
何かStrictな思想に基づいてるんではなかろうかと思って
質問したんじゃないのかな？

何故かそれに答えるのが「こうすれば文法違反にはならない」って話ばっかり。
>>243でも>>249でも繰り返して聞いているのにさ。

唯一ちゃんと答えている感じの>>245=250も
言い訳臭い長文になってるから説得力無いし。

俺？　俺はだから、単に仕様書いた人のミスだと思ってるよ。
そもそもブロックレベルにもインラインレベルにもなるんだから
どちらかで内容も変わるのに、それを説明する様な記法が
DTDには無いからこんな矛盾も出て来るんじゃない？

＞繰り返して聞いているのに
219が鈍いだけなんじゃ･･･
ここで正確な答えが得られるとも考えにくいし

>>298
こんばんは、>>219です。
>>243や>>249は同意見ですが私の書き込みではありません。
ええ、一人が繰り返して尋ねたのではないんです。
（でも、私だけが疑問に思ってたんではないとわかってよかった。）

>>290
弄れる訳無いって、見てから言ってますか?
モジュールとか言うと面倒に聞こえますが、全部テキストファイルなので
適当にちょちょいと書き換えるだけです。

DTD なんてぼっと見てるだけで何となくわかる程度のものです。

そもそもなぜ内包可能な要素が block level なのかを
*本気で* 知りたいのなら [email protected] などで聞いたらどうですか。

# noscript にどうしても頼る必要自体が理解不能だったりしますが。

XHTML って次々とバージョンアップしてますか?
PC 向け仕様は事実上 XHTML 1.1 が 1st release だと思います。

万人の要求を満たす拡張不要な仕様なんて誰にも作れません。
だから基本的に誰もが使いそうなものを用意し、拡張可能な形にして
必要に応じてモジュール構成の変更ができるような作りにしたのでしょう。

それが GUI ベースで簡単にできるようなツールが欲しいなら
オーサリングツールメーカに働き掛けたらどうですか。
要望がなければ需要はないものと思われても仕方がありません。

>>295 は、何か言うことが仕様策定に関わる事だと思ったのでしょうか。
HTML 仕様作成部門の人間は [email protected] とかを見ているのだから
これって変じゃねーか? と言う声を上げるだけでも十分意味はあります。
それが >>291 の言う「意見しろ」でしょう。

>>300
「適当にちょちょいと書き換えるだけです」、か……。
簡単に言ってくれますがね。それには理解してすっかり呑み込んでることが前提でしょ。
デキル人ってデキナイ君の困難を察してあげられないんですよね。
[email protected] ってのもどうせ英語でしょ？
仕様書のこなれない日本語訳をやっとこさ読み砕いてる人間にはムリムリ。
やはりXHTMLはHTMLよりもハードルが高い代物ですよ。

>>300
適当にちょいちょいと書き換えた例を見せてやって欲しい。
一つ例を得ることでそれを他に応用していける人もいるだろうし。
# 個人的にはそうして書き換えたものを XHTML1.1 と言ってもいいのかどうかを知りたい。

>>296
ありがとう！
嬉しくて涙が出たよ……

>>293,295
W3C には今でも意見をいえるじゃん。
今の仕様がおかしいと思うなら言えよ。
今後に反映される可能性はあるんだから。

>>304
なんだかそれって、小泉首相を批判してたら、
「政治に不満があるなら、選挙に行って投票で示せよ。
政局に反映される可能性はあるんだから」とやり返すのと似てる。
でもＷ３Ｃが日本語で意見を受けつけるのかね？
ブッシュ大統領に文句を述べたくても英語をよう喋らん人はどうすればいい？

>>305
Bugzilla-jp 並みのことを誰かがやるしかないんだろうね。

>>306
慶應大学がやるべきことなのではないかと思ふ。

>>305
英語をしゃべれるやつに頼めよ。
ここで愚痴っても仕方ねーだろ?

>>308
ここに英語がしゃべれる有能な友人を持つ人はいません。

みんな、喧嘩はやめようよ。
こんなのって不毛だよ。

ところで、おねがいがあります。
HTML講座という、
ちょっととんちきなスレッドがありまして。
http://pc.2ch.net/test/read.cgi/hp/1010398268/

HTMLを初心者にわかりやすく教えようという
方向にむかっているんだけれど、
なかなかそれが出来る人がいないみたい。

自分もStrictなHTMLを啓蒙したくて参加したんだけれど、
それが意外と難しくて、
手に余り気味。

どうしても参加してくれとはいえないけど、
できたら手伝って欲しい。
僕も、機会を見てできるだけのことはやってみたい。

>>307

費用対効果の問題ではないかと。
具体的には何をすればいいと思う?

営利団体でもないけどボランティア組織でもないからな。W3C。

はっきしいって仕様策定みたいなもんにまともに参加したいんだったら、
英語できないと本当にどうしようもない。まともに議論に参加できる程度の技術力と語学力をもつ人間に、対ローカル通訳みたいなもんをやらせるのもどうかと思うでしょ。

>>311
結局、英語の話せない奴は黙ってろ、ってことになるわけか。
そういう状況を問題視する人間が集結できないと難しいんだろうな。

>312
まあいろんなところで同じ論議になるような気がするけど。

「黙ってろ」とは違うと思うけど。
別に要求出すぐらいなら対した英語力も要らないしさー。

個人個人がなけなしの英語力出すのってコスト低いけど、
それを集中してどうにかしようって言うのはコスト高いじゃん。
国連みたいに全会議に五か国語同時通訳つけようとか、
そんな事はとても無理でしょ。

まあ、もうちょっとローカルサービスがあってもいいとは思うけどさ。俺も。

とりあえず、国内ユーザグループみたいなものを組織してW3Cに参加するとか、
何か相互協力みたいなものを求めていくってのはあり得る方向性だとは思うけど。

CSSコミュニティの中で英語が得意そうなやつに話を振ってみるとか

黙ってろ、と言うか、「これっておかしくない？」と言う確認なのに
「嫌なら自分でDTD書けやヴォケ」とか
「ウルセー。W3Cに直接言え」って返されたのが問題だと思うが。

>>302
XHTMLとは言えるだろうし、名前空間は同じでいいだろうけど、
DTD宣言にXHTML1.1のURNを書いたりしたら駄目だろうな。

>>310
取り敢えず、そのスレの状態じゃどうにも手が付けられないな。
1が成果をどこかにまとめてくれるって言うんなら助言のしようもあるけど。

>>301
はぁ?
最初から何でもできる様な人が居るとでも思っているのですか。

できる人は、それだけのコストを支払ったからできる人になったのであって、
最初は誰だってできない人です。

[email protected] は英語ですよ。それが何か?
archive を見て、以前似たような議論がなかったかとか
探す程度の事もできませんか。

>>301 はデキナイ君ではなくシナイ君ではないの。

意見を言うのには資格も要らないし、法的規制もない。
英語ができないなら翻訳でも頼んだらいい。

時間的なコストに余裕がないのであれば、
費用的なコストをできる人に支払ってできる人の時間を買えばいい。

何のコストも消費せずに愚痴を言っているだけじゃ何も解決はしない。


>>302
以前 NiAOU 氏が自身の日記の中で書いていたかと。
目的は違った気がするけど、どういった事をしたらいいかの
参考にはなるでしょう。

つか、exciteの翻訳でも使え。
時間はかかるけど、英語かける。また、単語の勉強にもなるかもしれん。
英語が駄目な奴のためにあるのに、そういう奴らは使うことすら知らんのか…呆れるなあ

>>315
>「これっておかしくない？」と言う確認なのに
>「嫌なら自分でDTD書けやヴォケ」とか
>「ウルセー。W3Cに直接言え」って返されたのが問題だと思うが。

全く同感。なんで>>316みたいにムキになって非難したがるのかな。
少々疑問を呈するのも排斥したがるのではホントに「信者」だよ。
（自分がコストをかけたからってそれを既得権益みたいに振り回すことはないよ）

つか、StrictならDreamweaverでそれ系のタグ使わずにちゃちゃっと作りながら修正すれば簡単に出来るような気もする。
DW4になってから無駄なタグさらに減ったし、CSSも一瞬で書いてくれる。また、デザインビューとコードビューあるのでタグに注意しながら書くことも出来る。
さらにタグは小文字だからXHTMLへの変換もたやすい。

みんな、DW使えば？

>>319
がんばれよ

DTDもベンキョウしたくありません。
エイゴもベンキョウしたくありません。
でも愚痴はコボシタイデース

だから、自分でDTD書けってそれを標準化してくれるなら書くけどそうじゃないでしょ

まぁ英語くらい使えるようになれよとは俺も思う

>>321

DTDも書けるし英語の多少はできるけど
愚痴をコボシタイデース

まあ、２ｃｈだし。ここ。

>>323
あはは、わかる気がする。

>>323
>>324

自作自演ならもっと良かった（ｗ

Scrictな話題はしないの？

正直Transitional推進派

Traditional？
理路整然なフォーマットに限って汎用性は思ったより出ない。
C++のクラスが良い例だと思う。

>>326
ここはStrictについて質問すると、
W3Cに訊け（当然英語で）って怒る恐いお兄さん達が多いから……。

Transitionalなんて邪道だよぉ
Transitionalで書くタグはCSSで全部補えるよぉ

>>330
target属性は無理でしょ。

ちょっと質問
前スレ
http://pc.2ch.net/test/read.cgi/hp/992708594/273-274
でいってるんだけど…「まーくあっぷ」って何て略せばいいかな？
値上げとかなわけ無いし。
つーか HyperTextMarkupRanguage って何て日本語訳してる？

>>332
Language??
JISでは「ハイパテキストマーク付け言語」だったかな。まんまじゃん（ｗ

>>333
うぉ…なんつーミスを…鬱氏

ハイパーテキストマーク付け言語ってまんま過ぎて
意味がよく見えてこないとか言ってみる。

作者名、サイト名、作成日、更新日、アクセス数なんかを
ページの一番下あたりに載せたいんだけど、
address でいいの？
それとも div class="property" ？
p class="property" ？

>>335
私は
<dl id="colophon">
<dt>管理人</dt>
<dd>名前</dd>
…略…
</dl>

>>336
ありが�d
ていうか colophon って単語初めて知ったよφ

Iswebを使ってるから広告がつくんで、一番上から少し間を空けたいんだけど
<br><br>
って方法で間を空けるのはやっちゃっていいことなんですか？
質問スレじゃないのにｽﾏｿ。

Strict的には、br等使わずにスタイルシートで
h1 { margin-top: 5% }
とでもして欲しい所。
#Canvasの一番上にある要素が分からないので、取り敢えずh1。

>>338
Strictならダメ。
スタイルシートでbody内の一番上に来る要素にmargin-top:2em;を指定しなさい。

>>338
Iswebの広告自体、strict的に結構微妙だから気にするな(w

>>332
「しるし（印）付け」ではどう？

「装飾」ではどう? 微妙に意味が外れてるか…

>>343
そういう烈しく誤解のもとになる語は却下。

テキストの訳語を誰も発明できずに今に至ってる時点で
コンピュータ用語の訳語は考えるだけ無駄って感じ。

「意味付け」じゃダメなの?

「超典刻印言語」とか。

「自然言語構成要素明示記号体系」

付標。

マークアップ＝値上げ

テキスト「白文」はどうか

>>302？
http://www.pcc.metro-u.ac.jp/~t0040238/xhtml-mod/sample/xhtml11-noscript-flow-samp.html
http://www.pcc.metro-u.ac.jp/~t0040238/ (↑リンク切れてる)

ついでにXHTML2.0 draft期待age

>XML文書に対するリンクの場合には、
>XPointer(XPathを含む)という機構が利用でき、
>「最初に出現するh2要素から次のh2要素まで」
>といった複雑な範囲を示すことができます。
>quote要素型というのは、この機構を利用して
>別ファイルからの部分的な引用を
>可能にするものではないかと思います。

いいなぁコレ

>>351
>ついでにXHTML2.0 draft期待age

おそらく今週は出ません。

>>352

残念ながらハズレ。なお似たようなことを実現するものとして
transquotation なんてのもあります。

http://www.sfc.keio.ac.jp/~ted/TPUB/TPUBsum

しかしながら、XPointer が IE とか Mozilla で使えるようになるのは
いつの日か...

>>353

がーそ

>>353
また延期か……。

<span class="red">***</span>
ってのは、REDな感じにしたいという、そういう意味なんだと思う。
色じゃなく。REDな感じにこだわりたい。それが大切。

>>357
「赤」以外の色になり得ないならいいと思うけどね。
<span class="red">〒</span>とか。

でも、単に「赤な感じにしたい」だけの強調だと、
「やっぱこれからは緑の時代だぜ」とか思ったときに
class名を変更しなきゃならないのでお薦めできない。

>>358
<span class="red">ガ○レッド</span>参上!
みたいな使い方なら別にかまわないんじゃない？
レッドの気持ちが沈んでて色がブルーになってもそれはそれでいいわけだし。

>>358.359
その使い方もちょっと違うと思う。
言いたいことはわかるんだけどね。

http://www.void.tako.org/mail/TextFile.html
このページの
[「山田太郎様」とすべきところを、わざわざ「山田太郎 様」]
この部分ですが、w3mで表示すると、下記のように様の前のスペースが
詰まってしまいます。

[「山田太郎様」とすべきところを、わざわざ「山田太郎様」]

これは、HTMLの仕様としては正しい動作なのでしょうか?

----------------------------------
||//
(@_@) Kusakabe Keiko
----------------------------------

>>358
<span class="red"></span>は例えば文書内で「赤いものを指す言葉」を示すため使うべきであって、「赤い文字で表示したい部分」を示す目的で使うのは駄目でしょ。
前者の用法なら別に赤色で表示させる必然性はないから、お好みとあらば緑色で表示させたって構わないことになる。

>>361
正しくないと思います。

>>362
この問題、いつまで経っても終わらないですね。
後者でも別に赤く表示させる必然性はありません。
class名を言葉として解釈することは無意味。
red でも dre でも　r03 でも同じこと。

（XHTMLの）XML宣言で、最後の?>の前に空白を入れている方が
時々いるみたいですけど、どういう意味があるのでしょう？

<?xml version="1.0" encoding="ISO-2022-JP" standalone="no"?>
と
<?xml version="1.0" encoding="ISO-2022-JP" standalone="no" ?>
のように。

<br/>じゃなくて<br />にしておいた方がmore betterだと言う話なら
聞いたことあるんですけど。

>>364
IEでXMLを開くと、詰めて書いてても、何故か空いて表示されるから、
それにつられてるんだと思う。

>>363
> >>361
> 正しくないと思います。
は取り消します。

http://www.w3.org/TR/html4/struct/text.html#h-9.1
を読んで、ご自身で判断願います。

>>364
<br/>じゃなくて<br />にしておいた方がmore betterだということと
同等の心理が働いているのだと思われ。

>>361
(意図的にか結果的にかはともかく)英文を念頭に置いた仕様になっているので
そのあたりは各 UA の解釈に依存するものだと思います。
「山田太郎 様」にするとか、いわゆる全角スペースをいれるとか。

>>364, 367
more better というのは最近流行の駄洒落ですか？

>>369
もう亡くなった某おばちゃまも使ってましたが？

>>370
ひきこもりのおばちゃまね。彼女が流行らせたんだろ。モアベター。

>>369
2重強調です。

>>364
XHTML1.1のDTD中では、マーク宣言閉じや処理命令閉じの前に
空白を入れている場合が多いので、漏れはそれに併せて
<?xml version="1.0" encoding="Shift_JIS" ?>
としています。

文書型宣言も外部パラメタ実体宣言の形式で。

Another HTML Lintで久しぶりにチェックしたら、点数が激減してた。
ファイルはそんなに改訂してないのになぜだと思ったら、HTML4.01での
<ruby>タグ使用に対し、以前は減点１だったのが今は減点７になってたからだった。
どうして急に減点を大きくしたのでせう。

まあXHTML1.1にすればいいのかもしれないが、XHTMLが閲覧できないブラウザもあるし、
ルビのためだけにXHTMLを勉強して移行するのも面倒だし……。

>>374
漢は黙って移行。単にXHTML文書にするだけなら勉強も要らん。

>>374
DTDの仕組みを知れば、HTML4.01でrubyを使ふなんて無茶はしなくなると思ふ。
ルビりたいなら黙ってXHTML1.1に移行しませう。
もしくはHTML4.01続行ならrubyを外すか、どっちか。
N6/mozならspanだけでもルビに整形できるし。

バグ辞典スレ向きかとも思ったんですが、取り敢えずこちらに……。

ruby内（rbやrt）で、HTML4.01で言う%inline;が使いたかったので、
DTDに記されていた例（xhtml11-flat.dtd・1042行目辺り）を使って

<?xml version="1.0" encoding="ISO-2022-JP-2" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % NoRuby.content "( #PCDATA | %InlNoRuby.class; %Misc.class; )*" >
]>
<html xmlns="http://www.w3.org/1999/xhtml" version="-//W3C//DTD XHTML 1.1//EN" xml:lang="ja-JP" dir="ltr">
（以下略）

と拡張したんですが、このファイルをMozilla（Mozilla {Build ID: 2002011403} (Windows)）に食べさせたら
Mozillaが吹っ飛んでしまいました。

これは、私の記述ミスなのでしょうか？　それとも単にMozillaのバグ？
一応、W3CのHTML Validatorでは問題なしと言われたんですが……。
#普通のXHTML 1.1に戻したらちゃんと食べてくれましたので、他に問題がある訳では無いみたいです。

すみません、"encoding="ISO-2022-JP-2"は間違いです、ISO-2022-JPです。

>>377
XHTML1.1ではデフォルトでrt/rb内にインライン要素を記述できるよ。
(ruby要素の入れ子を除く)

ruby.modじゃなくもっと上の方で上書き定義されているのでそれを見て下さい。
(ていうか同じ所でハマった経験がある…)

%NoRuby.content;の場合、フラットDTDでは2687行の記述ではなく
1046行の記述が適用されます。

ちなみに。
<!DOCTYPE html 外部識別子 [内部サブセット]>
の記述の場合、パーザの解析は「内部サブセット→外部サブセット」の順で行われます。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % NoRuby.content "( #PCDATA | %InlNoRuby.class; %Misc.class; )*" >
]>
と記述してしまうと、パラメタ実体参照"%InlNoRuby.class;"や"%Misc.class;"の実体が
未定義であるため、ここでエラーになる訳です。

これを回避するためには
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % NoRuby.content "( #PCDATA | &#37;InlNoRuby.class; &#37;Misc.class; )*" >
]>
として、%がパラメタ実体参照の開始と見なされないようにして下さい。
(&を&amp;と書くのと一緒です)

微妙に誤読したかも。

>>377
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd
も
http://www.w3.org/TR/xhtml11/DTD/xhtml11-flat.dtd
も定義は一緒です。(xhtml11-flat.dtdに一部ミスがあるっぽいけど)

xhtml11-flat.dtdはxhtml11.dtdを見易くしただけのものですよ…。

更に誤読ﾊｹｰｿ。連カキコすまそ。鬱。

>>377はちゃんと
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % NoRuby.content "( #PCDATA | &#37;InlNoRuby.class; &#37;Misc.class; )*" >
]>
って書いてたつもりだったのね(数値文字参照は展開されます…)。

それでmozがこけたとすれば、mozが悪いと思います。

>>379
あっ、そうか、先にある1044〜1048行の宣言の方が有効なんですよね。ありがとうございます。
#後に同じ宣言がある場合、そちらで上書きされるものだと勘違いしてました……。
#今まで、二日も掛けて何やってたんだ私は。
>>380
すみません、それは大丈夫です。どうやら、数値実体参照をそのまま書き込んだ為、
展開されてしまったみたいです。"&amp;#37;"と書けばいいのかな？
#って、上の実体参照を記すのにも実体参照を使ってるんですが……あぁ頭が混乱しそう。
>>381
御意。%Color.datatype;（でしたか）が無いのは有名なミスでしょうか？
>>382
はい、そうです。どうも、御丁寧にありがとうございます。

……ところで、382氏は、ひょっとしてsatoshii氏ですか？
#違っていたらごめんなさい。
いつも、興味深く拝見させて頂いております。件の拡張も、satoshii氏のサイトで勉強させて頂きました。
これからも頑張って下さい。一読者として、陰ながら応援しております。

http://isedit.infoseek.co.jp/cgi-bin/tnote/bbs1/101161855311188.html

この回答者達、すごい認識だな。

>>375
>単にXHTML文書にするだけなら勉強も要らん
でも「モジュール」って何のことだか理解できてないのに
<ruby>タグを使ってしまってもいいんでせうか。
正直、ＸＭＬってのもよくわからないままXHTMLに移行してメリットはありますか。

>>385
XHTMLを書くのにXMLを分かる必要はない。
分かってるとなお良いが。

>>385
＞正直、XMLってのもよくわからないままXHTMLに移行してメリットはありますか。

HTML4.01はSGMLで、XHTML1.1はXMLで、それぞれ定義されているわけですが、
SGMLを理解した上でHTML4.01を使っている人なんてほとんどいないでしょう。
ばけらさんとかすみけんさんとか、そういう人達は例外。

XMLは知らないがSGMLは知っているってのならともかく、
どっちも知らないならXHTML1.1を使っておいた方が無難と思われ。
XMLの基本構文は割と簡単に理解できると思うけど、SGMLは大変しんどい。

HTML4.01やISO-HTMLなんてのはマニアックな人達が使うものであって、
初心者が覚えるべきものじゃない。

# 原理的なことを知らなくとも使えるってのもHTMLの重要な利点ではあるけど。
# あと、385を初心者だって言っているんじゃなく、一般論としての話なので。

>>387
一部に反対。
HTML4.01はマークアップの原点に戻って、文書の各パーツにきちんと
意味づけをすれば混乱を防げるという趣旨で古い要素が統廃合されている。
<Hn>は見出しであって大きな文字を表示するタグではない、など、
体系的に理解するにはむしろ初心者向きではないかとさえ思う。

HTML3.2あたりなど、タグ乱立の様相を呈している。
結果、ひとつひとつのタグの用法を機械的に暗記していくことになりはしないだろうか？

もちろん初心者にいきなりStrict以外認めない、などと言うつもりはない。
でも、これから学び始めるなら、むしろStrictで基本的なマークアップができるように
なってからTransitionalや旧バージョンのHTMLでサポートされているタグを
習得していく、というメソッドも有効だと考えている。

>>388
＞<Hn>は見出しであって大きな文字を表示するタグではない
と言ったStrict的な概念はXHTML1.1に継承されていますし、
別に反対意見ではないような。

「StrictなHTML」という(理念的な)意味では、HTML4.01StrictもXHTML1.1も同様です・。
HTMLとXHTMLとで差があるのは構文だけでしょう。

構文的にはXHTML(XML)よりHTML(SGML)の方が遥かに煩雑ですから、
XHTMLの方が楽ですよ、という話です。

>>389
あ、了解。
部分に反応しちゃったね　スマソ

<dl>
<dt>4/7</dt>
<dd>昨日久しぶりに吉野屋行ったんですよ吉野屋・・・</dd>
</dl>
みたいな書き方はokと聞きました。
でも定義文でないならこのような使い方はしたくありません。
しかし日記を書きたい場合はどうすればstrictでしょうか？

<hn>4/7</hn>
<p>昨日久しぶりに吉野家行ったんですよ</p>

普通にこうじゃない？

オレは392のやり方だYO！

なるほど。
しかし勧告によしとされる例を
定義文でないからダメだと勝手に思うのはstrict精神に
反してはいませんか？いませんよね？

>>350

中国語ならこんなかんじ。

文本：テキスト
文本文件：テキストファイル
超文本標記語言：HTML

>>394
勧告で駄目とされてる例を良しとして使うのはどうかと思うけど、
良しとされてるものを駄目と思って使わないのは、別に問題ないと思う。

みまさｾｿｾｲー。週が変わりましたよー。まだですかー。

http://www.w3.org/2001/09/21-orf/xhtml-family/slide23-0.html

これ読んだら、XHTML2.0からMIMEタイプがapplication/xhtml+xmlになる
らしいけど。

試してみたら、IEはこのMIMEタイプをXHTMLとして表示できないんだよなぁ。

>>398
XMLアプリケーションに変わったからでしょうね。
SVGもapplication/svg+xmlですし。

> 試してみたら、IEはこのMIMEタイプをXHTMLとして表示できないんだよなぁ。
text/xmlで凌ぐとか（ダメ？）。

XHTML2.0が仕様上、新しいMIMEタイプでなければ
ならないのなら、そうするしかないな。
text/htmlでも可なら(たとえ非推奨であっても)、それで
凌ぐけど。

現在HTML4.01Strctでサイトを作成済みです。
XHTMLに移行するのには、タグを小文字にしたり、
空要素も全て「　/>」で閉ぢたりしなくてはなりません。中々修正が面倒です。
これを効率的になすのに良いツールはありますか。よろしくご助言下さい。

あと、NN4による閲覧者があるので、ページ内リンクを<a name>でやってます。
同時にid属性も振ってあるものの、XHTMLではnameが廃止されてるんですよね。
JavaScriptか何かでNN4に対してもページ内リンクを有効にする手立てはありませんか。

>>401
name が廃止されているのは XHTML1.1 。
XHTML1.0 なら name 属性も使えるよ。
それとも、 XHTML1.1 で書きたいの？

>>402
1.1が最新規格なんでしょ？　あ、2.0ってもう出たんですか？
あと、ルビも使用したいので。
それから、XHTMLにすると閲覧に支障が出るブラウザってありますか。
MacIEのver4.51未満が駄目ってのは知ってます。

>>401
>これを効率的になすのに良いツールはありますか。
『 >』を『 />』に一括変換するといー。

>NN4に対してもページ内リンクを有効にする手立てはありませんか。
ならば、そのままヨンストでいーのでわ。

ジレス。
>ならば、そのままヨンストでいーのでわ。

すまソ、ルビか。

>>404
>『 >』を『 />』に一括変換する
それだと“</p>”も“</p/>”になってしまふ。
>ならば、そのままヨンストで
「ルビも使用したい」って言ってるからHTML4.01Strictでは宜しくない。

googleで 「perl xhtml 変換」で調べればすぐにみつかるよ。
まあ、perlで変換が一番簡単じゃない？上から三番目のツールなんて便利そうだけど

MSXML4でもXSLTがtype="text/xsl"じゃないと効かないんだよな。
XSLT自体もXTransformとかに改名してほしい。

>>406
>それだと“</p>”も“</p/>”になってしまふ。

すまふ。<br>を<br />だ。<hr>を<hr />だ。imgは手打ちだ。headの中も手打ちだ。
首つって36回死んでくるわ。

正規表現使えや。
とりあえず秀丸でやる場合な。

<(br|hr|img|meta|link)[^>]*\f>：置換対象
\0 />：置換後

>>410
あと、baseもね。

>>407
そのソフト、非公開。
>>410
秀丸って持ってない人も多いよ（フリーでないから）。
それに、正規表現が何だかわかる人間なら質問すまいよ。
name属性消すのは一つ一つ手作業だしな、どのみち。

>>411
あれ、base って 1.1 では無くなったんじゃなかったっけ。

>>413
あります。

#ISO-HTMLでは削られましたけど。

>>412
でも、正規表現が一番てっとり早いはず・・・。
xyzzyなどなら秀丸以外にも正規表現で置換できるし、
name属性にしても、少しややこしめだろうけど消せないことはない。
この機会に覚えるとか。損はしないと思うよ。

# 「んなめんどくせぇことやってられっか！」と言うなら別。

XHTML 2.0 絡みの文章って、他にどんなのがあります？

現時点でXHTMLに移行する価値ってあるの？

>>417
うーん、結構自己満足的な部分も多いかも。
XML を利用するツールが使えるってメリットもあるけど、
んじゃ XML を利用するツールってなんだ？っていったら
XML バリデータぐらい？ってなっちゃうような。
そりゃ XML 十把一絡にしてたらそうなるわなあ。

DOM とか SAX つかって要素を簡単に弄れるようになるから
遊ぶ分には楽しいかも。
サイトのサマリ作ったりとかリンクだけ抜きだしたりとかね。

別に HTML でも出来るけど....

よく判ってる人教えてくれー。

>>417
XHTML1.1にすると、大手を振ってルビ（<ruby>）が使用できます。
まあXHTMLを宣言しなくても使ってるとこは多かったけどさ。

>>398-399
なんだか、W3Cは本当に後方互換性を重視しているのかと問い詰めたくなるな。

画像ファイルは全部pngにしてるという方どれくらいいらっしゃいますか？
pngファイルだとGIFなどよりサイズがでかくなることが多いんですが、
その辺気にしないようにしてるんでしょうか？それともデータを小さくできる
ソフトか何かがあるんでしょうか？

スレ違いな気もするけど他のところで聞くと「GIF使えやｳﾞｫｹ！」とか
言われそうなんで...

>>421
減色ちゃんとしてますか？
8bitのgifとフルカラーのpngだったら、サイズが違って当然なのだが。

>>421
あと、インターレースにするとサイズが大きくなりがちなのでご注意。
PNGのは、GIFのインターレースとは違う方式なので。

初歩的な質問なんですけど打ち消し線のタグってのは物理的要素なんでしょうか？

きちんと減色すれば同程度のサイズになるんですね。

なんか、やり方間違ってたみたい...
逝ってきます。。。

>>421
png の画像データは gzip とかと同じアルゴリズムを使った
zlib フォーマットで圧縮されてるてるから
画像ソフトによっては圧縮レベルが 1 だったり 9 だったりするよ。
# 大抵 6 だと思うけど、モノによっては設定できるソフトもある。

zlib は元々画像圧縮のために考案されたものではないから
画像の圧縮率を上げるためにフィルタリングという処理をして
これを補っている。5 種類のフィルタを混在させられるもんだから
それこそアプリによってクセがあったり無かったり、結果は様々。

あと 1x1 みたいな極端に小さい画像の場合は
ヘッダ情報の長さが短い分まず GIF の方が小さくなる。

>>424
s,strikeは物理要素です。文字通り「打ち消し線」以外の意味は持ちません。

一方、delもIEやNNではデフォルトスタイルが打ち消し線ですが、
これは「削除済みの項目」という意味の論理要素です。

なお、delは必ず打ち消し線で表示されるとも限りません。
例えばLynxではデフォルトスタイルが

del:before {content:"[DEL:";}
del:after {content:":DEL]";}

みたいになっていたはず。

>>423
strictには打ち消し線のタグはありません。

>>420
ものすごい勢いで同意。
本当にそうする必要があったんだろうか。
最近いいかげん呆れてきたッス。

>>420
んー、でも、現在のWWWってのは、まだまだ初期段階の
不安定で未熟な技術だと思う。

後々面倒なことになるよりは、今のうちにどんどん「やりやすい」仕様に
変更して欲しい。これがもう三年経ったら、ちょっとしたことを変更するのが
物凄く大変になってしまう気がする。

>>401
http://www.tomato.sakura.ne.jp/~y-arena/atelier/textss/

話、変えちゃって悪いけど
みなさん、W3CのHTMLチェックとかで得たバナーは
ローカル保存して使用してる？

HTML4.01のバナーをローカルに保存して
右の白いトコを透過にしたいんだけどいいのかな？

>>432
使うときはローカルに保存しるけど、改変は宜しくないと思われ。
建前上というか、常識的にはな。

# もしかすると、みんながバラバラにローカルに保存するよりも
# W3Cから直リンしてた方がキャッシュで処理できたりして
# とらふぃくを減少できたりするかとか思ったが
# んなこたぁーないよな。

>>433
やっぱりダメですよね。
ありがとうございます。

# 直リンしてるんだけど
# たまに表示が遅いんでローカル保存について聞きました

>>421-423
421じゃないが、
PNGってGIFより小さくなることが多いけど
GIFより大きくなることも2〜3割の確率である。
1色ベタ塗りみたいな極端に小さくなるタイプの画像はGIFの方が小さくなったような。

ちなみにPNGは保存するソフトによって結構サイズが変わるよ。
ソフトによってフィルタリングの上手下手があるみたい。
俺はOPTPiXでやってる。
こいつだとPhotoshopとかでやるより2〜3割小さくなるかな。

先に質問した者です。ご教示下さったみなさん、有り難うございました。
しかし折角ご助言いただいたのですが、
>JavaScriptか何かでNN4に対してもページ内リンクを有効にする手立てはありませんか。
これに対しては有効な手段が無いみたいですし、今から「正規表現」てのを覚えて
何とかXHTML1.1に変換しても、rubyが使用できるだけでは苦労の割にあまりメリットがありません。
ましてや2.0だとなんだか後方互換性に難があるみたいですし。
当分HTML4.01のままで、移行は見送ることにしました。

>>438
XHTML 2.0 はまだ草案も出ていない将来的な規格です。念のため。

今XHTML2.0で書くメリットはありますか？

なんつったりして

>>439
AAくらい貼れYO!

>>436
Kanzaki氏のとこのperlスクリプトで一発やん。あとは手書で修正。
まあ、わざわざperlをインストールせなあかんが。

>>436
perlスクリプトならここにもあるよ。
http://www.wig.nu/~ohtaki/soft/index.html

>>412
>>407 に書かれていたソフト、シェアウェアになってるみたい。3,000円。
http://www.w-frontier.com/printed/cnvxhtml.html
ちょっと変換してみた（試用ということで、お金は払ってない）んだけど、
なぜか <br> や <hr> が <br /> などになってくれない。バグ？

>>432

> If you like, you can download a copy of this image (in PNG or GIF format) to keep in your local web directory, and change the HTML fragment above to reference your local image rather than the one on this server.

なので、手元に置くのは自由だと思うが。
改変はまー、それぐらいならいいんじゃないの？

>> 436

tidy (http://tidy.sourceforge.net/)
の -xhtml オプションを使うなんて手もある。

>>444
Winの話題ですが、Tidy GUIを使うと、複数のファイルを一気に変換できないし、
DOSで使うと、文字コードを指定できないで、エライことになってしまいます。
こんなヘタレな俺に、アドバイスをくだされ。教えて君でスミマセン。

ｶﾞｲｼｭﾂだったらすまないが、打ち消し線を使うギャグって結構見られるよな。
例えば、

>>432
著作権的に問題あり。<s>漏れはやってるが</s>

みたいなの。これにdelを使う奴をよく見かけるんだが（特に4.01準拠を謳うサイトに多い）、むしろsのがマシだと思う。
em.bokeみたいな打ち消し線付文字を示すクラスを指定するのがベストか？

>>446
delもsも変だと思う。
かといって強調しているわけでもないから、emも変だと思う。
となればspanに打ち消し線のCSSを設定するのが一番妥当だと思われ。

・著作権的に問題あり。<span class="gag">漏れはやってるが</span>

ちょっと前に話題になった強調の逆（弱める）の要素が実在すれば、
そっちを使いたいところだけど。

うむ　言われてみれば<del>はおかしいな確かに。

>>446
ギャグにもいろいろな種類があるから、class="gag"では他の箇所で
困ったりせん？
むしろclass="strike"ってのはどうなのか？

日本語が許されるなら、class="ぼそ"あたりを使ってみたい（ｗ
スタイルシート側でうち消し線、音声出力用にちょっと低くて小さな声。

打ち消し線でも良いけど、文字色を薄くするのも良いかも。
ユーザビリティー的に問題有りかも知れないが。

>>447 強調してると思うけど。強調の「強」に拘りすぎ。

意味的にいったらgagとかjokeとかしなきゃいけないんだろうけど、なんか、無粋だなあ。
それに、CSS2非対応の音声ブラウザでそのまんま読み上げられてしまうと、文意が伝わらないどころか文章が変になることもあるし。
（ていうかdel/insをそのまま読み上げる仕様だったらどっちにしても意味ないか）

>>451
span class に対して「意味的」とか言うのは、いいかげんやめてほしいな。

>>451
ソースなんてコンピュータが読みとるものなんだから、無粋なのは当たり前と思われ。
CSSの利点のひとつはソースの視認性が上がることだが、これは管理上の話だし
classの値なんて任意なのだから、あなたがｶｺｲｲと思う値にしていいと思う。
ただ、class名からその部分の位置づけがわかるようにするという原則が尊重されてれば。

CSS 非対応でそれなりに意味が通るようにするんだったら
em.whisper とか strong.whisper かな。

ところで、em と strong の使いわけって結構悩むんだけど。

>>450
「弱めてる」ように見えても、よくよく考えると強調してるってとこは
結構多そうだね。

でもサブタイトルあたりはそれじゃ片づかないような....

>>452
どうして？

>>253
それは分かってるんだけどさ。

間違えた。
後半は>253じゃなく>>453ね。

>>455
絡む気はないんだけど、それがわかってたらなぜ>>451？
文法上の議論に無粋も何もないような気が。
sageだから何となく感想を書き込んでみただけなのかしら。

# 末節なので特に強く返事を求めてはいませんし、責めるつもりもないです。

>>454
強調したいなら em で、それよりも更に強調したいときは strong でしょう。

>>458
いや、そりゃわかるんですけど、
どういう部分で更に強調すべきかってのの判断がいまいち。

<p>
それじゃ恒例の。
「<em>1</em>、<em>2</em>、<em>3</em>、<strong>ダァー!</strong>」
</p>

みたいなのばっかりだと楽でいいんだけどもん。

>>458-459
<p>
今回のレッスンでは、相手の名前を尋ねるときの丁寧な表現について学びました。
</p>
<div class="example">
　<p>
それでは例文を示してみましょう。
　</p>
　<ul>
　　<li><strong>May I ask your name, please?</strong></li>
　　<li><em>お名前を伺ってもよろしいですか？</em></li>
　</ul>
</div>

↑とか↓とか。

<p>
私はウェイトレスに<em>アイスティー</em>を注文した。
だが、実際にやってきたのは<strong>アイスコーヒー</strong>だったのだ。
</p>

>>450と思ったが、英文の例は<dl>の方が適切な気がしてきた。
<ul>を使うとしたら

<ul>
　<li>英文
　　<ul>
　　　<li>邦文</li>
　　</ul>
　</li>
</ul>

を最小単位にしないと複数の例が挙げられないな。

>>460
<p>
私はウェイトレスに<em>アイスティー</em>を注文した。
だが、実際にやってきたのは<strong>アイスコーヒー</strong>だったのだ。
しかも、<stress>虫が入っている</stress>ではないか！
</p>

みたいに、さらに強調の段階が入る場合は？
それだったら、はなから em 一個か strong 一個でいいじゃんって思うんですが。

>>462
(現状の) HTMLでは力不足ということで諦めるのも１つの手だと思うが。

仮に em あるいは strong 1つだったとして、それを入れ子にするのか?
>>462 はそんなに入れ子にしたいのかと問いたい。
強調レベル属性のようなものを用意する手段もあるだろうが、
>>462 は(以下略)

>>463
なんか、論点がずれてきたんで...
strong と em の使いわけはどんなふうにするべきかねーって話です。

>>462 の場合、

しかも、<strong>虫が入っている</strong>ではないか！

とすべきか、

だが、実際にやってきたのは<em>アイスコーヒー</em>だっのだ。
しかも、<strong>虫が入っている</strong>ではないか！

とすべきかって話です。

>>460,>>462
そもそも、その例の二つ目の強調部分には
strongが必要なのだろうか。
個人的にはemでいいように思える。
まぁ、「んなこたぁ漏れの気分次第だろが！ｺﾞﾙｧ!」
といわれればそれまでだけど。

というか、>>462みたいな理屈が通ってしまうと、
いくらでも上限無く必要じゃないかという話になる。
だから、敢えて二段階まで、としているのじゃないだろうか。

# 現状でのHTML的理論構造上の限界がこの辺ってことだろうね。

>>465
h* が h6 までってのと同じような理由ってことで納得しときます。

そういや、XHTML 2.0 では h* は h に統一されるんでしたっけ？

何となくemとstrongの関係はh1-h6の関係に似てるなーと思う。
XHTML2.0でsection-hという要素型が導入されるとすれば、
emとstrongも二種用意する必要なかったんじゃないかと思うのだが。
(実際あると楽ちんなんだけどさ)

あと、dfnとかaとかciteとかっていうのは、みんな「特殊な」強調だと思うわけで。
em.dfnを要素にしたものがdfnというか。
qのように単に文の状態を表すものは、span.qを要素にしたものみたいな。

# ひとりごとみたいな内容になってしまったけど（ﾟεﾟ）ｷﾆｼﾅｲ!!

>>467
もし、強調を意味する要素が一つになったとして...

<em><em><em>重要!!</em></em></em>

ヤダァ....

dfn とか var とかって、他の html の要素とレイヤーがずれてる気がするよ。
中途半端な意味付けってかんじ。

>>462
漏れは
<em>問いたい</em>
<strong>問い詰めたい</strong>
<em><strong>小一時間問い詰めたい</strong></em>
としてる。以前どこかで見かけたのの真似。

必要ならクラスを定義するくらいしか思いつかないが、
とりあえずこれ以上強調が欲しいと思ったことは無い。

なんかバカくせーやり方。そこまで行くとビョーキだね。

>>470 至極単純明快だと思うぞ。それでこそ、strictって感じ。

>>469
んー、469氏の伝でいくと、em、strongの次は<em><strong>...なの？
俺は<em><em>...だと思っていたけど。

<em><strong>と<strong><em>は同レベルの強調？　それとも分けてる？


#単なる質問なんで、気を悪くしたらｽﾏﾝ。

>>470のやり方
<font size="4">問いたい</font>
<font size="5">問い詰めたい</font>
<font size="6">小一時間問い詰めたい</font>

マジっぽくてアレだが。スレ汚しスマソ

いや、そんなとこまで逐一細かくタグつけなくてもって思ったの。
「もっと他にタグつけれる所はないかあぁぁ？」って光景が浮かんだ。
言葉が汚くなったのはごめん。

質問。

<dl>
<dt>コーヒー牛乳<dt>
<dd>ミルクとコーヒーでできてる。</dd>
.
.
.
</dl>

とするのと

<dl>
<dt>コーヒー牛乳<dt>
<dd><p>ミルクとコーヒーでできてる。</p></dd>
.
.
.
</dl>

とするのとどっちがいいの？
要するに<dd>に直接コメント書いてもいいの？ってことです。

>>457
>sageだから何となく感想を書き込んでみただけなのかしら。
そういうことです。

>>475
OKです。
前スレかどこかで既出だったと思うんだけど、見付からなかったので手短に言うと、
要するにddはliやtdと同様に考えて下さい。

直接<dl><dt>りんご</dt><dd>赤い</dd></dl>として構いません。

もっとも説明が「段落」を形成するならpとしてマークアップするべきだと思いますし、

<dt>なんとか</dt>
<dd>
　<p>これはこういうもので…</p>
　<p>かつこういうものでもある…</p>
</dd>

のような説明と並べるなら、

<dl>
　<dt>項目1</dt>
　<dd>
　　<p>ほげほげ</p>
　　<p>ふげふげ</p>
　</dd>
　<dt>項目2</dt>
　<dd>
　　<p>ほげほげ</p>
　</dd>
</dl>

のように、統一感を持たせた方が良いと思いますが。

>>475
<dl>
<dt>コーヒー牛乳<dt>
<dd>ミルクとコーヒーでできてる。</dd>
.
.
.
</dl>
とありますが、まず2行目のところから間違ってますよ。

>>478
あげあしとるのは勘弁してあげようよ。

>>477
ありがとうございます。
わかりやすい説明で勉強になりました。
>>478
どうも。いや全くそのとおりです。

オレは
<dl>
　<dt>項目1</dt>
　<dd>
　　<p>ほげほげ</p>
　　<p>ふげふげ</p>
　</dd>
</dl>
ってのは
<dl>
　<dt>項目1</dt>
　<dd>ほげほげ</dd>
　<dd>ふげふげ</dd>
</dl>
としてる。

>>481

[がいしゅつ]
　意味:「既出」の意味。
　語源:とあるｽﾚで「がいしゅつかもしれませんが…」と書いた>>1がいたことに起因。

↑これはdl>dt+dd+ddが良いと思う。

[がいしゅつ]
　「既出」の意味。とあるｽﾚで「がいしゅつかもしれませんが…」と書いた>>1がいたことに起因。
　発祥元のｽﾚはどこだったか忘れたが、「どこそこの女子大生が絞殺云々」というｽﾚだったような。

↑これはdl>dt+dd>p+pの方がしっくりくるような。まあ好きずきだろうけどね。

ちょっと質問なんだけど、１つの段落を丸ごと強調したい時って、
みんなどうしてる？

●段落内まるごと強調タグ
<p><strong>「既出」の意味。とあるｽﾚで「がいしゅつかもしれませんが…」
と書いた>>1がいたことに起因。発祥元のｽﾚはどこだったか忘れたが、「どこ
そこの女子大生が絞殺云々」というｽﾚだったような。</strong></p>

●段落にクラス名
<p class="strong">「既出」の意味。とあるｽﾚで「がいしゅつかもしれませ
んが…」と書いた>>1がいたことに起因。発祥元のｽﾚはどこだったか忘れた
が、「どこそこの女子大生が絞殺云々」というｽﾚだったような。</p>

後者の方がスマートな感じがするんだが、
スタイルシートを切った（or利かない）状態でも強調の意が伝わるのは
前者だと思うんだ。

>>483
前者かなぁ。
後者はクラスで強調の意を表してるけど、
いくらクラスを付けても所詮pはpだし。

うーん、class は意味付けのためにあるって解釈でいいのかな。
というか、<div class="...">..</div> なんかまさしくそんな感じで使ってるけど。

>>464
使いわけは >>458 に書いたとおり。
強調のレベルが3段階以上の場合は、(現状の)HTMLでは力不足。


>>483
もちろん前者。

>>483
CSSを使って、
・強調段落の文字色を変えたい時→前者
・強調段落の背景色を変えて、蛍光ペンでなぞった感じにしたい時
（行間に通常の背景色が現れる場合）→前者
・強調段落の背景色を変えて、四角く塗りつぶした感じにしたい時
（行間も通常の背景色ではなくなる場合）→後者
・強調段落全体を四角く枠囲いしたい時→後者

あまりStrict的な考え方ではないかもしれないけど、俺はこうしてる。

>引用にq要素とblockquote要素があるんだから
>例えば強調にもstrong要素とblockstrongがあってもいいだろう。

という意見なら分からんでもないが、
やっぱり<p class="strong">〜</p>だと違和感があるな。

いくつかの段落の中で特定の
「段落（群）」を強調させたいなら、
<div class="strong"><p>〜</p></div>
でいいんじゃないだろうか。

ただ、自分なら段落の内容がたまたま強調する
部分しかなかったと考えて前者にすると思う。
ins要素でその段落に文章を追加する時にも
その方が融通が利きそう。
それに、そもそも段落そのものを強調する
ということがstrictなのかどうかも疑問。
少なくとも、慣習的なやり方ではないと思う。

<p class="strong">ほげ</p>
のように、擬似的な要素を作るのは好ましくない。

しかも、段落全体を強調って言っても、

<p class="strong">これはこういうことだと思うんだYO!</p>

の場合は良いかも知れないが、この段落に文章を追加したくなったらどうするの？

<p><strong>これはこういうことだと思うんだYO!</strong> 何故かって？　それは…</p>

結局、強調されているのは段落全体ではなく、あくまで段落の中のテキストだ、
ていうふうに考えてる方が何かと都合がよいと思われ。

<strong class="low">
<strong class="high">
こんな使い分けでいいんでないかい？

>>483
段落ごと強調などしない。
「結論」にあたる段落は頭に持ってきて、専用のクラスを定義してる。

>>489 の意見に近いのかもしれないが、文章中の特定の段落を強調するってのは
文章として間違ってると思うぞ漏れは。

ホームページって言葉つかわせてくれよ
なんだよひゅーなんとかパッカード社って
そんなの知らねえよ。

なんでここで言うんだｙｐ

>>484-492
ありがとう。参考になったよ。

みんなの意見を聞くうちに、強調すること自体が重要なのではなく、
何故強調したいのかが大事なのかもしれないと思った。

俺がしたかったのは、小説みたいなページで、会話文だけを強調したかったんだよ。
で、今まで俺は、

　<p>彼は言った。</p>
　<p><strong>「逝ってよし！」</strong></p>
　<p>すると相手は即座に、</p>
　<p><strong>「オマエモナー」</strong></p>
　<p>と言い返した。</p>

とか、

　<p>彼は言った。</p>
　<p class="strong">「逝ってよし！」</p>
　<p>すると相手は即座に、</p>
　<p class="strong">「オマエモナー」</p>
　<p>と言い返した。</p>

みたくなるんだと思って（誤解して）た。
でも、みんなの意見からすると、

　<p>彼は言った。</p>
　<p><strong class="talk">「逝ってよし！」</strong></p>
　<p>すると相手は、</p>
　<p><strong class="talk">「オマエモナー」</strong></p>
　<p>と言い返した。</p>

とか、

　<p>彼は言った。</p>
　<p class="talk">「逝ってよし！」</p>
　<p>すると相手は、</p>
　<p class="talk">「オマエモナー」</p>
　<p>と言い返した。</p>

とかするべきなんだよね？　きっと。

っていうか、p と strong が同じレイヤーに存在してるのが
そもそもの間違いの元だとおもうんだが。

p は構造で、strong は意味でしょ？
W3C にヴォケ茄子と言いたい。

>>496
＞っていうか、p と strong が同じレイヤーに存在してるのが
＞そもそもの間違いの元だとおもうんだが。

そうか？　この二つが密接に関係しているからこそHTMLはHTMLなんだと思うが。
少なくともW3Cに文句を言うのは筋違い。
元々SGMLがそういう言語なんだから、文句はISOにどうぞ。

>>496
意味をマークアップする要素が無いとして、

<p>それは<strong>絶対変だ</strong></p>

は、

<p>それは<span class="strong">絶対変だ</span></p>

としたほうがいいということでしょうか?

<span class="strong">みたいなのは、よく使いそうなので、
<strong>をあらかじめ用意してあるんじゃないかなぁ。

>>497
んじゃ。
ヴォケ茄子、季節外れなんじゃ>ISO

>>498
<p class="notice">
熊パケット網が流行中
</p>
<p>
某所からの報告です。
ただし、<span class="notice">北海道限定</span>とのこと。
</p>

意味と文章構造って交錯するものじゃないの？

>>500

御意。
だから、「レイヤーを別に」というのは、ちょっと違和感があるんです。

>>501
ええ、だから、交錯するからこそ
レイヤー別にするべきじゃん？ってことですが。

別にしとけば、strong な p はどうやったらいいの？
なんてこと悩む必要なかったんだと思うんだけど。
どうですか？

>>502
レイヤーを記述する別のメタ言語みたいなのが必要だってこと?

>>503
うーん、そうですね、
属性で記述するようにしとくべきだったとか。
class なんかうってつけじゃないですか？

なんか、もう、XML でいいじゃんって感じです。

>>504
結局面倒だからhtmlに、strongがあったりするし、
xhtmlがあるんじゃないかと思う今日この頃。
xmlでもいいけど、UAの実装とか考えたら、htmlの資産は、大きいですよ。

>>505
でもなんか、美しくないです。

>>506
美しさを求めるなら、ｘｍｌはより美しくないんじゃないかな。
それこそレイヤーもへったくれも無いような気がしますが。
業務的には（謎）、htmlのつもりでxhtml使っといて、いざとなったら、
名前空間で逃げればいいかと。
まぁ、美しくないのは確かです。

そりゃ、後方を気にしているうちは美しくはならないだろうね。

XHTML 2.0 て、後方互換を無視する仕様になるんでしたっけ？

<a xlink:href="hoge.html">hogehoge</a>
とかになっちゃったら、後方互換的にはきついかも知れないが
(この辺未定って言ってたよね？)
でも対象がそもそもXMLパーザである以上、そのくらいは構わないと思うのだが。

XQuery とか XLink とか XPointer とか
ぜんぜん理解らないんですが、
双方向リンクを作ったり、ある"範囲"に対してリンクしたり
出来るようになるんですよね？

こういうのが使えるようになるんだったら
もう昔のしがらみなんてバッサリやっちゃってくれて結構です。

IE とか Mozilla とかで使えるようになるまで
たとえ五年とかかかろうとも、脳内で翻訳するから漏れは幸せになれます。

>>510
後方互換は各サイト運営者がxml版とhtml版を用意していくことで補完するしかないだろうな。
ただ、「普通の」ページ作成者がHTMLから離れるのはまだまだ先の話（そんな時代が来るのかは微妙だが）。

漏れはページ作成はずっとhtmlかxhtmlでやっていくと思う。
新たに得られる事と覚えなければならない事を考えると移行する気にならない。

ザンジバルのように後方は無視した実装で行くべし。
それが漢

後方を無視するサイトが増えないと、いつまでも古いブラウザを
使いつづけるアホどもが減らないからな。

Microsoftって、そのためにセキュリティーホール作ってるんでしょ？

class名って論理的じゃないとだめ？
おれのとこのBBSの色を変えるところを

.cool{color:blue}
.heat{color:red}
.moe{color:#f0f}
とかしてたけどバカらしくなって
.blue{color:blue}
.red{color:red}
.pink{color:#f0f}
に変えたよ。

色を変えるためにマークアップするべきじゃない

てゆーか、#FF00FFってピンクか？
元の.coolとか.heatっていうのもなんか違うと思うんだけど。
書き込む時に文字色を選べるようになってて、
青とか赤とか、そのまんま指定するのであれば、それでいいと思う。

恐れながら質問をさせていただいても構いませんでしょうか？
レベルの低い質問で申し訳ないのですが。
私、現在XHTML1.1でソースを書いておるのですが、W3Cにてチェックしたところ、
Error: element "input" not allowed here; possible cause is an inline element containing a block-level element
というエラーが出ました。
よろしければ直し方を教えて頂けないでしょうか？
あらましは、
<div id="bbsform"><form method="post" action="petit.cgi">
<input type="text" id="email" size="20" />
・
・
・
</form></div>
となっております。
検索はしてみたのですが良く分からなくて。
ここなら良い知恵を
授けてくださるかと思い。投稿しました。

form直下にインライン要素は置けない。
fieldsetとかdivを入れとこう。

関係無いけど、inputにnameはいらんの？
idで値をcgiに渡せたっけ？

>518
答えは >519 が示してくれているので，とりあえず日本語の lint の URL でも．
エラーメッセージも日本語のほうがわかりやすいのではないかと．
ttp://openlab.ring.gr.jp/k16/htmllint/htmllinte.html

>>519さん
>>520さん
どうもありがとうございました。
無事解決致しました。
idはnameの写し間違いでした。
すみません。

>>509

上の方のリンクから飛んでくと読めるW3Cの記事でも
そんなことは書いてあった。

でも、section要素新設しながら、h1〜h6に加えて新設される
見出しクラスを限定されない見出し要素がhなんだよ・・・。
headingに何故しない？って感じ。

美しくしようという気はさらさらないらしいW3C

1要素につき12バイト少なくて済むから

恐れながら質問させていただきます。

[サイトのロゴ]
ナビゲーションバー＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
ページのタイトル
本文（以下略）

このようなデザインですべてのページを作る場合に、
サイトのロゴをH1にするべきなのか
ページのタイトルをH1にするべきなのか迷ってます。

サイトの中の1ページであるからサイトのロゴがH1という考え方もできますし、
そのページの主な内容がタイトルであるわけだからタイトルがH1という
考え方もできるように思います。

そんな些細なことで悩むなといわれればそれまでですが、
信者的にはどっちでしょうか？

そのページのタイトルがh1にきまっとる。

>>515
ほんとにバカらしい。
.a {color:blue}
.b {color:red}
.c {color:#f0f}
で十分だよ。論理的だし。

head があるのに heading 作ると紛らわしい

なんて理由かも

小説のHTML化についてなんですが
文章の区切り方が2通りあって
ひとつは空行、もうひとつは「*」とか記号を並べる場合があります。
意味は、前者は時間の進行、後者は視点の変換だと思っています。
どのようにマークアップするべきでしょうか。

空行は直前か直後のパラグラフにclassつけてマージン指定だろうね。
或いは時間ごとのまとまりをそれぞれdivで包括するか。

後者も<p class="視点の変換">*******</p>
とするかなあ。自分だったら。

>>528
「*」とか記号を並べることに意味がある場合は
そのまま
<p>*******************</p>
にすればどうよ?

>>528
俺なら、<hr class="〜" /> で。 <object>*****</object> なんかもいい。

******という表現が視覚的であることを考えると、<p>でマークアップしてよいものかどうか。
>>531が挙げている<hr>がもっとも近い気がする。

あとは、******を画像で用意してしまう手もあるかも。
たとえば * 1個分が 30px x 30px の透過GIFだとして、以下のようなスタイルを組み合わせては？

.view-change{
　padding-bottom: 50px; /* [*]の画像を表示するために十分なpadding */
　background: url(./astarisc.gif) bottom repeat-x;
}

<p class="view-change">
本文
</p>

アスタリスクがこのスペルでいいのか知らんが。

>>532
区切りが構造として入らないので、スタイルに頼るのは良くないと思う。
……というか、ここでは、なるべくスタイル化しない方向で考えましょう。

<hr /> が嫌でも、明示的にobjectの挿入の方向で、よろしく。

>>533
ああそうか　区切りは視点が切り替わるポイントだから、直前の段落に入れたらあかんのね。
言われてみたらその通りだな。

<hr class="time">とか<hr class="view">とかで対応できないですかね？

hr.time {visibility: hidden }
hr.view {background-image: url("asterisk-line.gif") }

みたいにして。hr.viewの方は適当です。
hrのスタイルっていじったことがないので。

>>535です。>>531-534ですでに出ていましたね。
リロードするまで>>530までの記事しか読み込めてなかったようで。
すいません。

>>523

それだったらsection要素なんて新設しないで、
sc要素とかにすればいいんだ。

>>537
それだと"soft core"と勘違いされかねない。
W3Cは良く考えている。

HTML仕様書の11.2.6によれば、
th,td要素の属性のうちwidthにつき、
HTML4.0ではwidth = pixels [CN] ですが
HTML4.01ではwidth = length [CN] です。
これについては「附属書 A: 変更点」にも記載されてないみたいです。
いったい変更の理由はなんなのですか？
Web上のHTMLレファレンスでも両方の定義があって混乱させられます。

SVG 混在の XHTML 文章はどう思います？
ヘッダ文章を修飾するのに SVG を使ってるようなケース。

これはデザインとコンテンツ分離に失敗してるケースでしょうか。

>>540
図である必然性があるなら何の問題もないと思うけど、
ただの飾りというのはどうなんだろね。

Wiki みたいなのを正しくマークアップするにはどうしたらいいんでしょう。
いや、違うな、どういう文章構造にしたらいいんでしょう？だ。

W3C信者的にはXHTML1.1で<applet>タグをどう扱うのがベストなのでしょうか？

>>543 <marquee> と同列に扱う。

>>544
ﾜﾗﾀ

知り合いにW3C信者というのは初めて見るサイトはコンテンツを見ないで
いきなりソースを見て
「なんだよ、文章宣言もないじゃないか　フ」
と鼻で笑う人種と聞きましたがそうなのですか？

>>546
そういうやつはきっと文章宣言を見つけても
即行W3C HTML ValidationにURL突っ込みそうだな。

>>546
そうです。基本でしょう。(w

>>547
チェッカーにかけなくても、点数がわかるくらいでないと信者とは言えません。

文章宣言なんてものに出くわしたら腹抱えて笑って即刻晒すだろ。

>>549
そいつが友人ならチェッカー要らずだ（ｗ

view-source:http://www.cc.rim.or.jp/~sho_h/takepod/
はちゃんと文章型宣言でてるよ。

誰かそろそろつっこもうぜー

>552
オイラの知らない宣言してる！（ｗ

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

ってだめ？

>>555
それぞれの P 要素の内容が段落だという強い信念があるならば許可。

Sentence Type Declaration
<!SNTTYPE SYSTEM "myown.std">

>>555
なんか過去レスにあった気がする。

そもそも段落ってなんなんだ？

pは段落じゃないよ。パラグラフだーよ。

パンダグラフ

パソピア7

>>560
でも、パラグラフは段落だけどね。

単に段落というと和文の「形式段落」のことのように受け取られがちな気が。
あえて「意味段落」と呼んだ方が良いように思う。誤解を避けるということで。

>>564
形式段落に p 使っても、何の問題もない。
何故そんなことに拘るのか？

>>565
形式段落と意味段落を同一視して何の問題もないということはないよ。
だからそんなことに拘るの。

>>566
<div>の使い方によっては両者をきちんと区別できる気がするが
Strict的にはそれではだめなん？

葉と丸の
<p><a href="#top">先頭へ</a></p>
は段落？

>>566
h* の使われ方のバラエティーに比べたら、そんなことはたいした問題ではないと思う。

所詮"程度"問題かい

>>570
だって、HTMLだもん。なるべく要素の種類を削る方向で考えないと。

>>567
それもアリとは思うけど、
p要素の意味はもともとparagraph（意味段落）なのだから、
UAには div（意味段落）>p（形式段落） ではなく
div（意味段落より大きな集合）>p（意味段落） と
解釈される可能性の方が高いのではないかと。
もしそういうUAがあれば、の話ですが。

それよりは、pの原意をそのまま使って
p（意味段落）>span（形式段落） とした方が
良いのではないか、と思うのです。

>>572
つまり、形式段落が邦文に独特の用法だから、欧文由来のHTMLでマークアップしきれないという指摘なのよね？
(現行の)HTMLはp内にブロック要素を持てないから、邦文のスタイルとなじまないってわけだ。

しかし。
＞p要素の意味はもともとparagraph（意味段落）なのだから、
＞UAには div（意味段落）>p（形式段落） ではなく
＞div（意味段落より大きな集合）>p（意味段落） と
＞解釈される可能性の方が高いのではないかと。
＞もしそういうUAがあれば、の話ですが。

pはまさに段落だけど、UAはdivはブロック要素としての解釈しかしない。
DTDにブロック要素としての位置づけしかされてないんだから、それ以上の勝手な解釈はしてはならないはず。
意味段落をdivでまとめた場合、そうすることで「ああ、これは意味段落なんだな」と解釈するのは
閲覧者になるのではないかと思う。

そもそも欧文に「意味段落」「形式段落」の区分が存在しないなら、pの原意は「段落」であって
「意味段落」ではないのでは？
# ほんとに欧文に形式段落がないのかは知らんが。

ま、あくまでHTML4.01Strictまでの範囲でどこに落としどころをもっていくかの話で、
XHTMLでpがブロック要素を内包できるようになりゃそれに越したことはないと思うけど。

英語に意味段落、形式段落の違いがないって本当？

なんにしても、全世界の全ての文章の表現に適用出来るような仕様とは
いいがたい部分もあるということで。
…既出ですね。

素朴な疑問なんだけど paragraphって、本当に意味段落なのかなあ。

INやNNなどのUAで、スタイルシートを使わないデフォルトの状態では、
paragraph と paragraph の間って、必ず１行空くよね？

「１行空く」という形式が必ず適用されるってことは、
paragraph は形式段落なのかもしれないと思ったんだけど。

それとも paragraph って、日本語の形式段落と意味段落の中間の性質の
ものなのかな？

HTML ってそこまで階層構造な言語じゃないような。
もっと平面的な構造で
意味段落は h* とか hr とかで区切れということなんだと思ってた。

既出っぽいんですけど、
ul とか dl にキャプション付けるときって
どんな要素使ってます？
つか、caption 要素、リストにも使えてもいいと思うんだけどなあ。

title 属性でいいのかな...

>>576
1行空くのはMosaicからの慣習だろ。
英文が基準だからそうなってるだけで。
和文の感覚で考えても答えは出ないんじゃないか。

むしろメールの書き方とかの慣習だと思うけど。
印刷物だと欧文でも和文同様に字下げで段落表すこと多いよ。

>>578
>>140 に一つの案があるよ。でも俺もリストに caption 欲しい。

どなたか>>539の疑問を解いて下さる方はいらっしゃいませんか。

>>582
パーセント値も使えるように直したんだって。
http://www.w3.org/TR/html4/appendix/changes.html#h-A.1.3

>>583
あ、そこですか。成程。
すると、ばけらやとほほのHTMLレファレンスは
4.01ではなく4.0で記述してるんですね。

>>584 ばけらやとほほで聞けよ

>>584
ばけらは HTML4.0 の Transitional DTD を元にしてるって明記してるね。
とほほのは微妙だな。 HTML4.01 での変更に沿ってる部分もある。

>>584
HTML 4.01に修正した箇所もあるよ。
http://www.ne.jp/asahi/minazuki/bakera/html/updatelog
の
> 1999-8-29
に
> PR-HTML4.01 と言うものが出ておる。少々気が早いという噂もあるが、リファレンスをこれに対応させてみた。
> HTML4.0 からの仕様変更は、
（以下略）
と書いてあるし。TDに付いては書かれていない所を見ると、単なる見落としだと思われ。

付いては → 就いては

だな、ｽﾏﾝ。

うざいよ。ばけらのところでやれって。

>>587 PR-html401 の時点ではまだ pixels だよ。
http://www.w3.org/TR/1999/PR-html40-19990824/struct/tables.html#h-11.2.6

>>589 ｼﾂｺｸﾃｽﾏｿ

>>589
ｼﾂｺｸﾃｽﾏｿ

>>590
しまった、RECでの修正か。御指摘Thanks。

strictはbr、hr,span,div,物理タグ不可でよろ

物理"タグ"（ｗ

>>592
うーん...
div とか span "要素"はなぁ。
なくなると意味付けに困る。

よくよく考えると"強調"だから strong に class 付けして...
ってのは、どっか違うと思うので。

br と hr は名前がアレだけど、
構造化するのにそんなに邪魔なものとは思えない。

brはソースを汚す
hrはみかけだけだー
と言ってみるテスト

brってあまり使いたくないんだけど。こういう場合はどうすれば良いんでしょう？
Perlのソースを表示する。
<p>
<code>
#!/usr/bin/perl<br />
$script = "./bbs.cgi";<br />
(以下略)
</code>
</p>
私はこんな感じの時にbrを使ってるんですが、もっと良い使い方ありますか？
preも考えたんですが、長い行の場合、横スクロールが出てしまうのです。

hr{width:1px; height:100px;}
は水平線でなく垂直線になるのでstrictじゃありませんか？

brの話が出てふと思ったのだが、昨日の意味段落/形式段落の違いを、
以下のように表現すれば？

br{ margin-bottom: 15px; }

<p>
意味段落のはじまりはじまり。昔々あるところに、ﾓﾅｰさんとｷﾞｺさんが…
………………
………………
形式段落の終わり
<br>
形式段落の始まり
二人はﾓﾅ太郎を大切に育て、ﾓﾅ太郎もすくすくと育って…………………
………………
………………
意味段落の終わり
</p>

それでもbr好きぢゃない人には抵抗はあるかもですが。

>>598
それだとインデントが表現できない…。

>>596
preでいいよ。長い行は自分で折り返せばいい。
ソースコードって、そういうものじゃん。

英語には意味段落と形式段落が無いのか？
英語の本でも意味段落を「*」や三行空きで示すことはあるぞ。

パラグラフと意味段落・形式段落の違いには拘るのに、
改行の事情の違いには拘ってないのかしら？
和文なら、<br />をたくさん使ってもいいことにすればいいじゃん。

>パラグラフと意味段落・形式段落の違い
そもそもそれがよくわからないな。何が異なるのか。
paragraphは段落。段落を種類に分ければ意味段落と形式段落がある（英語でも日本語でも）。
――これで何か問題がありますか？

>>603
御意。俺はその辺まったく拘ってない。
拘ってる人は片手落ちなのかもしれない
と疑問を感じているのみ。

>>600 に追記。
pre内の長い行、右端で折り返さないエディタでも
ブラウザと同じ表示になるよね？

私は、p要素の元になっている英語のパラグラフといえば、
最初や最後のセンテンスがそのパラグラフの主題、
トピックセンテンスになっているという種類のものだ、と
ずっと思っているのです。

で、個々の「段落」それぞれに主題と呼べるようなセンテンスがない、
というか見やすさや小気味の良さのためだけの「形式段落」までも
パラグラフと見なすことには抵抗を感じる。

上で挙げられていた例でいえば、
「ふるいけや」
「かわずとびこむ」
「みずのおと」
それぞれをぶつ切りにして、そこにそれぞれ
トピックセンテンスがあると言えるのかどうか。
私は、言えないと思う。

こういう理由で、私は形式段落とパラグラフの違いに
拘っているのです。
（よって、形式段落の方はspanなりbrなりで表すのが
ベターなのではないか、と）

参考資料:
http://dictionary.cambridge.org/define.asp?key=paragraph*1+0

>>596
code{white-space:pre;}

>>597
CSS切った時にそれでもStrictなら。

>>602
＞和文なら
根拠は？

>>605
そういう場合のためのoverflow:auto

(from Cambridge International Dictionary of English)

paragraph, abbreviation para
noun [C]
a short part of a text, consisting of one or more sentences and beginning on a new line. It usually deals with a single event, description, idea, etc.
You'll find the reference in book 2, paragraph 4, line 56.
The news rated only a few paragraphs in the local newspaper.

par・a・graph　　
　
n.　（文章の）節，　段落；　段落標，　パラグラフ記号　((¶))；　（新聞の，見出しのない）短評．　
−　vt.　文節に区切る；　（ニュースなどを）短い（新聞）記事に書く．　


gooによると見出しのない 短評らしいけどhnつけちゃだめなん？

なんか、pre の存在意義が疑わしくなってきた。

>>597
hr って horizontal だかそれに類似する言葉の略なんじゃなかったっけ。

break とかだったらまだよかったんだけど。

HR = Horizontal Ruleね。

>>597
短い（長さが1pxしかない）水平線だからいいんじゃないの？

p{white-space:pre;}

しかしIE6で閲覧すると、xhtmlだとxml宣言が不正になりpreにならない
結果html4.01で書かなければいけないワナ。

そう言えば、縦書きの時はやはりVertical Ruleになるんだろうか＞Horizontal Rule

CSS3 module: text
http://www.w3.org/TR/2001/WD-css3-text-20010517
はまだ読んでないからよく分からん。

>>600
確かに、そうですね。うーん。

>>608
とりあえず、それで凌ぎます。
ただ、対応してるブラウザが…(;´Д`)

>>614
がーん。だからIE6でやってもpreにならなかったのか…。
XHTMLｳﾂ。

>>613
前スレで既出な議論だけど、
Horizontal っていう見た目(?)が名前に入ってるのが評判悪いみたい。

>>616
文章型宣言文の前に文字が入るとだめらしい
ﾏｲｸﾛｿﾌﾄ逝ってヨシ

>>618 だからさぁ文章型宣言ってなんだよう〜
でも M$ 逝ってよしには禿同

それにしても標準モードでないと white-space:pre が効かないって
どういう理屈なんだろう？ 理解できん。

ソースコードにさえ pre を使わないなんて……。
そのうち、表にさえ table を使うなとか言いそう。
すぐCSSの話に持ち込もうとする人には、
このスレに来てほしくないよ。

>>606
なんで段落と呼んでおけばよいものを「形式」段落とか呼び分けねばならないのか
まだ理解できません。
例に挙がった「ふるいけや」は短詩なのであって、詩であれば<pre>を使用して
整形すればよい。preの用例にはソースコードだけでなく詩もあったはず。
また一行で改行する短いパラグラフ＝段落があっても別に変ではない。
英文でもそれはあることです。
英文

>>621
でもそれじゃあ、codeってなんのためにあるんですか？

オイラも聞きたい　>>621

<pre><code>.禿同{font-size:150%;}</code></pre>
というように2個内包スレ

>>623
違うでしょ。
pre はプログラムリストのためだけにあるわけじゃないよ。
逆に、プリフォーマットしないプログラムリストもあるし。

code と pre は競合するものではないと思うが。

>>623-624
621じゃないけど、622が言ってるようにpreの中身が詩のこともある。
あくまで「preは整形済みテキスト」「codeはソースコード」です。

つーか、code とか var とかいらねえよ。
そんなん採用するなら date とかもっと一般的な要素採用しれ！

注釈要素キボン

>>628
データでない文字など存在するのだろうか

整形済みテキストは見栄えに関する要素だと思う漏れはDQNですか？

>>629
漏れもキボン

>>630
よく見れ。

>>631
確かに pre は見栄えに関する要素に思えるけれど
改行に意味があるテキストというのが存在するんだから
しょうがないんじゃない？

その整形に、マークアップするだけの意味があるのならpre
見た目を整えるのが主目的ならwhite-space:pre

日本独特の詩歌やなどは区切りの意味での改行が
在って然りと思うけれど、プログラムなどのコードの
整形に見た目以外の意味があるのかは疑問。
もっと言えば、詩歌さえなければ
pre自体がstrictなのかどうかさえ疑問。
brでも間に合うわけだし。

br より、行であることを示す要素があればいいんではないかなと。

>>636
XHTML 2.0 で導入予定です

>>635
詩歌の場合は br ではダメなの？

プログラムコードの場合、一続きの文字データを
br 要素で分断することへの抵抗感みたいなものはあるなあ、俺は。
文書の幅に合わせて勝手に折り返されては困る場合もあるだろうし。

>>635
というか、preよりもbrこそstrictでないと思うのだが。

>>638
詩歌だって折り返されちゃ困るのけど。
というか折り返し云々はスタイルシートの問題かと思われ。

# つーか、このスレ異様に活気づいてない？
# 何かあったのか？

折り返しだけでなくpreなら空白（スペース）の固定も考慮してよ。

>>622
段落と名の付くものは全部p要素で良かろうという考えに立てば、
一行ごとにp要素でマークアップすることもアリになり、
そうしたことでデータ的な意味の分断がbrやspanによるものより強くなれば、
原文の意図が損なわれてしまうのではないか、と。
そこに拘っているんです。

そんなの作者の立場から見てもどうでもいい事だと
言われてしまえばそれまでの話なんですが。

>>641
そのことで「原文の意図が損なわれてしまう」のであれば考慮すべきでせうね。
しかしそんな場合ってどんな例があり得るのかちょっと思ひ当りませんナ。

>>640
ところで、xml:space属性とwhite-spaceプロパティ
XMLとCSSで別々に対応しているのはどうなのかな。

詩歌とか。
まぁこれはpreで良しと既に上のほうで結論が出てますけど。
そういうことです。

>>639
段落の話が出ると、こうなりがち。

>>643
xml:space はどう表示するかは規定していないから、
white-space とは関係ないよね。

>>635
> 日本独特の詩歌やなどは区切りの意味での改行が
> 在って然りと思うけれど、プログラムなどのコードの
> 整形に見た目以外の意味があるのかは疑問。

あらら。perlやjavascriptでコメントを書いた経験がない人ですか。萎え。

code samp kbd varなどは文書内の役割を明確にするから、Strict的だと思うけどな。
良心的なブラウザならcodeでマークアップされた範囲は等幅フォントで表示するはずだから
そのサンプルソースを参照する人には見やすいと思うんだが。
見た目上の問題ならスタイルシートでカバーできるが、要素そのものに位置づけが明示されている
code samp kbd varなら非視覚系UAにも情報提供が容易になる可能性が高い。

preのテスト。

<p>ウザい↓</p>
<blockquote>
<pre>
アイコラ画像のサイトなんだけど早く見ない
と話題に乗り遅れるよ。

http://www.lime-jp.com/02/
</pre>
</blockquote>

>>648
そりゃそうなんですけど、その定義されてる種類が中途半端かつ偏ってる
っていいたいんです。

例えば、単語として意味をなさない id 要素とか、
日付を表す date 要素とか、もっと作るべきものはいっぱいあると思うんですわ。

実際、音声ブラウザなんですけど、
2002/1/28 は "いちぶんのにせんに、にじゅうはち" って読んじゃいます。
文脈から判断するの不可能ですよ？
1/28 は 1分の28 かもしれんし。

だから、中途半端な意味付けなんていらない。
別レイヤで提供出来る仕組みにするべき。

>>650
別レイヤで提供するとどうなるんだろ……規格上は単純化するが、素人に扱いにくくなったりせんかな。

ま、date要素なんかがあれば確かにありがたいとは思う。
反面、細かい話だが日付の表示法はバリエーションが多い点で難しさはあるかも。

2002/1/28
02/01/28
1.28.2002
01.28.02
Feb 28, 2002
2002年1月28日
壬午年睦月二十八日

これが全部同日を表すわけで……ってこのへんは非視覚系UAの実装の問題ではあるか。

>>650
現状での対処は

<ruby class="date"><rb>2002/1/28</rb><rt>にせんにねんいちがつにじゅうはちにち</rt></ruby>
ruby.date rt {display:none;}

とか。

文脈から判断できないのは漢字なんかでもおなじことだし、
人間でも正しく判断できないこともある。

「国境の長いトンネルを抜けると…」は「こっきょう」なのか「くにざかい」なのか、とか。
判断できる人、いる？

>>652
別スレでは <span title="2002年1月1日">2002/1/1</span> で回避、
って回答がありました。

理想を言えば、すべての漢字にルビふってあったほうが
コンピュータ的には助かるんでしょうね。

入力するときは一意に読みが判ってるんだし、なんとか出来ないかなぁ。
どう読むかをユーザ任せにするっていうメタ情報を含ませてるんだとしたら
なおのことややこしくなりそうだ....

>>651
うーん、素人って code とか var とか使ってませんよ？
＃少なくとも私の周りでは。
どこら変を素人と見るかによって変ると思うけど。

別レイヤにするっていっても、
タグによるマークアップを止めろといってるわけじゃないです。

XHTML にして、別ネームスペースで取りこむとか。
文章の内容によって取りこむ意味セットを変えるとかしたら面白そうじゃない？

小説特有の意味付けとか、プログラム特有の意味付けとか。

日付。
それこそ lang とか xml:lang 属性で回避出来そうじゃない？

>>653
いや、あなたの発想は間違ってないと思います。
HTMLがコンピュータ由来であるがために、要素にも偏りがあるのではないかという
指摘も納得がいってます。
651まではあくまでHTMLの範囲で考えていたので、XHTMLに移行して新たにDTDを与えるとかなら
もちろんその方が無理がないでしょう。
# 特に、lang属性に着目する視点は鋭いと思う。

しかし、読み(≒ルビ)の情報までファイルに持たせると、データ量が著しく増えそうな気が。
現行のインフラでは少しきつい気がします。
ま、現行のHTMLの話ではないけれども。

つか、Excelで表を作ってHTML変換したときに、指示した覚えもないルビが大量に振られてて
大いに萎えた記憶があるのよね(´д`;)
どでかい表だったから楽をしようとしたんだが、あれはよけいつらかった。
読みの部分を別ファイルにして、閲覧者がそれを利用するか選択できるくらいのシステムでないと、
逆にソースの可読性を下げてしまうおそれがある。
# イメージとしては、ブラウザで画像をOFFったりできるのに近いかな？

dateは同意。今はclass="date"で、スタイル適用させてる。
var や code や def って、知ってても面倒だから書かないことが多い。
数式は変数だらけなんだよ！

>>653
lang属性をどう使うってのか今ひとつ解らないのだが。

>>655
だからそれはMathMLだって。

<dl>
<dt><code>p{font-size:18px;
line-height:150%; }
em{font-size:20px;}</code></dt>
<dd><p>p要素直下のem要素の行間は30pxではなく27pxとなる</p></dd></dl>
みたにソースコードをdtにいれたい場合はpreをいれれないからwhite-space
しかあかんよな・・しかし実際はbrでやらんとブラウザによっては横続きになってしまう。

>>657
それは、dtに段落やブロック引用を入れられないとかいうのと同じで、
dl の使い方が間違っているのでは？

プログラムのソースコードは忠実に改行を再現する必要があるもので、
且つまた、再利用性を考えれば、余計な文字（<br />とか）を途中に
挟むことも許されないものであるので、pre を使うのが最適。

そうは言っても &, <, >, はそのまま書けないんだから、
<br /> や を使えばいいとも言えるが。

>>660 &#xA; が消えました。

>>658
でもそういう 2 個の要素間の関連を記述できる要素とか属性とかﾎｽｨ。

>>662
現状では見出しと本文の関連すら記述できないしね。

W3Cのxhtmlにxml宣言ないじゃん。
よいの？

必須ではないよん

>>664
W3Cのサイトに期待しても無駄でしょう（ｗ

ソースコードは改行されちゃまずい。スタイルシートで横スクロールを出ないようにすると
($no,$name,$mail,改行
$uri,$msg) = split(/\s/,$valu);
こういう風に表示されちゃって、初心者さんは迷ってしまう。だから素直にpreを使うのが良いとは思う。
でも見た目は美しくないんだよねぇ。(;´Д`)

>>664
文字コードが UTF-8 なら xml 宣言はなくても可。

>>666
Perl あたりはまだ改行の影響を受けにくい方かもとか思った。
シャレにならないのはセミコロン自動挿入を行う JavaScript かも。

あぁ、そういえば文字コードって何が一番良いんでしょうかね？
何にとって、という目的によって違うような気もしますが。

>>666
改行の影響をもろにうけるVBScriptなら、preホシー

日本語のファイルでutf-8は重いよ。
多言語でもないページでutf-8,16,32を使う意義はあるの？
shift_jis軽い。

>>670
そのテキストを処理するプログラム側の事情で
Unicode 使わざるを得ない時はあるな。

html4.01つかっていいよね？
だめ？

いいよん

>670
あなたの環境ではね。

>672
そのサイトの用途によりますね。

>666-669
コピー&ペーストでなら全く問題なし。>659に同意。
読んでもらうことだけが目的なら雑誌での記述のように
「ここは改行せず1行で記述」という意味の画像でも
置いておけば十分。

>>674
>「ここは改行せず1行で記述」という意味の画像でも
>置いておけば十分。
こういうのを CSS でやりたいよね。
:first-letter みたいな擬似要素で
:line-break なんてあってもいいと思う。

画像でいいんだよ。

いや、擬似要素でもつかわないと改行される場所特定出来ないだろっていってるんだが。
>>676 はどこに img 要素置くの？

pre:line-break { url('return.png'); }

>>675
昔 Bugzilla でそんな要望見たなあ。引用を表す ">" を
blockquote:each-line:before { content: ">" }
とかって指定したい、みたいな提案だった。ほったらかしになってるけど。

>>677
わかるとこならどこでもいいんじゃないの？例えば、

<p>TAB区切りで書いたテキストをdt,ddに変換するPerlスクリプトは以下の如し。</p>
<pre>
<code>
#!perl
while (<>) {
s/([^\n])\t/$1\n\t/g;
s/\t(.+)/\t<dd>$1<\/dd>/g;
s/^([^\t\n]+)/<dt>$1<\/dt>/g;
print;
}
</code>
</pre>
<p><img src="dt_dd.png" alt="" width="209" height="69"></p>

とかじゃ駄目？

heightがシックスナイン

同じディレクトリへのリンクの場合

<link rel="stylesheet" href="./main.css">
か
<link rel="stylesheet" href="main.css">

どっちが美しい？

あ、にたようなので。

http://www.hoge.com/~hoge/ にリンクするのと
http://www.hoge.com/~hoge/index.html にリンクするの、どっちがいいかな？

そりゃ、両方が意味するものは違うんだけど。

あと、サイト内部でも。

index.html と hoge.html があって、hoge.html から index.html にリンク張る場合
<a href="./">index</a> と <a href="index.html">index</a> のどっちがいいか。

うちのサイトは

./ =./start
です

>>682
http://www.hoge.com/~hoge/ の方が自由度は高い。
例えばこれならトップページ(？)のファイル名が変わっても
リンク先を変更する必要がない。
XMLに移行してindex.xmlにしたいときとか便利。

(バーナーズ・リーは同様の理由から
「ウェブ上のリソースには拡張子を書かない方が望ましい」としているわけで)

あ、どっちかというとききたかったのは

<a href="./">..</a> と <a href="./index.html">..</a> なんですけど、
省いたほうがよさそうですね。

サーバ側からすれば、ファイル名まで指定するほうが嬉しい。
<a href="./">index</a>だと最初はカレントディレクトリにある（サーバが指定したファイル）RootDocumentを探しに入る。
だけど<a href="./index.html">index</a>の場合は最初からindex.htmlを探しに行くから負担が少ない。
同様の理由で、以下のような指定は負担が大きい。
http://www.yahoo.co.jp
↑最後のスラッシュがない。最近よく見るけど、最後のスラッシュなくして記述してる奴。
これだと、まずディレクトリの検索から始めるからね。
まぁ、負担っていってもそこまで大きくないんですけどね。htaccessを検索するのと同じで。

>>686
最後のスラッシュ、ルートディレクトリの場合は
(省略可能だから)関係ないと思うけど。

http://www.hoge.org/ と http://www.hoge.org は同じディレクトリを指す。
http://www.hoge.org/hoge はルートディレクトリにある"hoge"というリソースを指す。
http://www.hoge.org/hoge/ は"hoge"というディレクトリを指す。

.htaccessで index.cgi -> index.shtml -> index.html の優先順位で走査させてる。
indexを自動作成するスクリプトを置いてるディレクトリもあるから。
で、それぞれのファイルに base urlをルートディレクトリの indexにしているので、
うちのサイトの場合は a href="./" == virtual="/"

>>687
すんません、書き込んでから気が付いたんですけど訂正するの面倒だったんで。（ｗ

>>674
いや、処理が重いのではなくて、
ファイルサイズが重いといいたかったのよ。

htmlがまともなサイトは地味なとこ多くない？

>>691
たぶん、HTMLを勉強してる人は、厨房がやるようなデザインが嫌いなんだよ。
そうすると読みやすい（見やすい）デザインにしようとする。
まぁ、読みやすく・シンプルでカッコイイデザインが難しいというのもあるけどね。
文章系サイトだったら地味な方がいい。

lint厨まるだしの
link要素が
<link rel="start" href="./">
のみある今の状況を打破していいですか？

>>693
もちろん<link rev="made" href="mailto:〜">もあるよな(w

>>694
なんとなくコンテンツ内にメールアドレス晒すのがいやだからそうしてまつ。

>>695
いやそうでなくて、Lintで100点を取るためだけに
<link>要素を追加していることを言っているんだろう。

>>696
左様。
トップページと掲示板とリンクページしかないのにstartもnextも
あったもんじゃねえ。

トップページ→start くらいは書いててもいいんでないの？
検索で辿り着いた人がトップページに迷わず到達できるように、とか。

のの字がとほほのstartだけしかないlink要素をばかにするから
こうゆう悩みが出て来るんだよ。

「みんな、accesskeyってどうしてる？　tabindexは？」
http://pc.2ch.net/test/read.cgi/hp/1006224399/
link要素についても若干触れられている。
論じているのもいいが行動するとさらにいい、と思った。良スレ。

>>699
それは馬鹿にする方が馬鹿じゃないの？
動機はどうあれ結果としてアクセシビリティ・ユーザビリティの足しになるのなら、それは評価して良い。

24時間無カキコ阻止＆アゲ

なんかピタッとレスが止まったな（ｗ

1時間おきにageなのか？

現在のデザインとコンテンツを分ける仕組みは間違ってるんじゃないかって思
えてきた。

赤線の引いてある部分は... とか、上記の例では... とか。
そういう文章の書き方が悪いってか？あほらし。

デザインがコンテンツであった場合のうまい書き方ってないんじゃない？
ドキュメント自体にもメディアタイプ指定出来るようにすべきだと思う。

>>705
デザインがコンテンツなら画像を使うだろ。使わなきゃアホ。
HTMLで書く以上、UAによって表示が異なるのは必然。

>>706
そうか？
じゃあ赤い下線をひいた文章を書きたかったら全部画像にするの？
文章の出現順序保証したかったら全部画像にするの？

＞Strict な HTML(*) について語るスレッド

StrictなってどんなHTMLのことをいうの？

>>708
>>1 に書いてあるじゃん。

>>707
赤い下線のほうはその通り。むしろ、そんな文書はHTMLで書くなと言いたい。

出現順序は気にしなくて良い。出現順序を変えるスタイルが
デフォルトになってるわけないから。

赤い下線を引いた部分を別の場所で説明するなら……

<style type="text/css">
dfn a{background:url(./red_line.gif) bottom repeat-x;text-decoration:none;}
</style>
・・・・・・・・・・・
なお、<dfn><a href="./foo.html#bar">厨房</a></dfn>は相手にしないのでそのつもりで。
・・・・・・・・・・・
<p id="bar">ところで、視覚系UAでは赤線で示した部分だが、この言葉は実際の所・・・</p>

こんな感じでいいんでねーの？
出現順序の意味がわからんけど、順序が大事なら id="0" から使い方が沸いてこない？
tabindexとか使えない？

つか、707はHTMLに適さないドキュメントを無理やりHTMLにしようとしてないか？
HTMLはメディアのひとつであって、既存のすべてのメディアの代替ではないよ。

と思ったらidは数字から始まっちゃいかんのだな。
id="num0"とか適当でいい気はするが。

>>711
デザイン的要素でもコンテンツに含まれる部分ってあるんじゃないかってこと。
強調文字が赤いのは機能的見地から分離可能だけど、
赤い文字に意味があるなら、"赤い"っていう情報は内容と不可分だよね。

>>710
では、HTML ってどういう文章を書くためのものなのか説明してくれると嬉し
い。煽りじゃないです。正直、HTML はどんな文章でも表現出来るようにする
方向に向ってると思ってたので。

>>711
上記、とか、下記のような文章と id とか tabindex が結びついてこないんですが....

>>713
断言できる自信があるわけではないんだけど。
デザインそのものがコンテンツの重要な部分を占めるとしたら、
あえてStrictにこだわる方が無理があるんではないかな。

実は私は素材屋をやってたんだけど、画像を求めてくる人ばかりだから
あえてStrictを捨てて無理やりなデザインをしたし、テーブルを使ったレイアウトもやった。
それは見る人を視覚系UAに限定したからの話ですが。

赤いことに意味がある状況っていうのもこれと同じで、視覚系UAだけを対象にした
ドキュメントを書いているなら、視覚的な情報に依存したマークアップになり得る。
でも、これは必ずしもStrictから離れるわけではない。
なぜなら「Strictか否か」は文法の問題であって、視覚系UAのみを対象にすることの
是非はアクセシビリティーの問題だから、関連はしているが同一ではない。

705の「赤い線」は本文の記述であってマークアップではないから、あえて言うなら
「本文のアクセシビリティーが低い」のであって、マークアップやスタイルシートの
使い方によっていくらかのフォローは可能かと思う。

んー　なんか要領を得ないレスになってしまった。
具体例が出せるなら出して欲しいかも。

# 「上記」「下記」は「前述」「後述」で書き換えればいいような気がするけど。

>>709
HTML 4.01, XHTML 1.0, XHTML Basic 1.0
とかのことなんだよね。
（見たけどマジで分かんなかったんだよ。）

>>708
深読みすると的を得た言葉かも。
StrictなHTML、っていう意味ならばTable使いまくりもStrict。
HTMLの古いバージョンはHTMLでレイアウトをする事を考えてたんだから。
少なくともtableもbも4.01trans.以前はvalidだった。

ここの住人の「Strict」は>>716のいう通りHTML4.01以降あたり、「文書の意味」を定義する事に主眼を置いた論理マークアップ。

>>715はそもそも画像を並べてるだけで「文書」を書いているわけではないのだから構造化文書の書き方を考えなくてもいいと思う。

ちなみに「赤いことに意味のある文字」の話はｶﾞｲｼｭﾂと思ったが漏れの気のせいか？

bcokquoteのcite属性にいれるuriも

&は&にすべき？

&は&amp;にすべき？
でした
あとhead属性のpriofile属性のuriは
相対uriでいいのでしょうか？

上記、下記ってのは構造上の前後関係を指し示すのにそのまま使えるかと。
必ずしも↑、↓って意味じゃないでしょう。縦書きの文章でも使うし。

strictなページ作成を目指し、拡張子を消したのですが
.htaccessの設定がわからないっす・・
拡張子なしをhtmlファイルとして認識させるにはどうすればいいの？

教えて君ですまないけど
AddType "text/html; charset=Shift_JIS" .html .htm

を拡張子なしにする場合はどうすればよいのでしょうか？
三毛猫とか見たけどちょっとわからなかったもので
どうか教えてくださいませ。

掲示板の "昔の10件" なんかを link 要素で書くときって
rel="prev"？ それとも rel="next"？

>722
ディレクトリ示してるんだろ

>>722
ForceType text/htmlぢゃないかしら？
ミケネコから拾ってきたんだけど。

>>723
自分だったらNext。
分からなくなったらBookmarkに逃げる（ぉ

あ、bookmark の使いかたもよく理解らないんだった。
どう使うの？
まさにしおり的使いかた？

てか、しおりって読んでる人が使うもんだよね。
やっぱりよくわからないです。

>>713
＞正直、HTML はどんな文章でも表現出来るようにする
＞方向に向ってると思ってたので。
方向としては全く違うことも無いだろうけど、
少なくとも現段階では無理だと思わざるを得ない。

>>717
ｶﾞｲｼｭﾂだね。

>>718
HTMLのコード内では全てすべきかな、と。
>>719
特にかまわないと思う。

>>720
以前、「同じ行の直前で言っているのに、そのことを
上記と言っている文章」を見て違和感を覚えた。
前述後述のほうが安全な気はする。

>>723
revとrelの意味を知っておけばわかると思う。
ちなみにその場合はrel="prev"ね。

属性の構文について確認しておきましょうか。
HTML4.01での属性の書式は、大まかに三通りあります。

1. 属性名=属性値リテラル (例えば checked="checked")
2. 属性名=属性値 (例えば checked=checked)
3. 属性値 (例えば checked)

「属性値リテラル」というのは「置換可能文字データ」を引用符で括ったものです。
1.の書式の場合には、属性値リテラルから一般実体参照と文字参照を
展開した文字列が「属性値」としてアプリケーションに渡されます。

つまり、属性を「属性名=属性値リテラル」の書式で記述した場合、
リテラル内の"&"は一般実体参照の開始、"&#"は文字参照の開始
と見なされますから、文字データとしての"&"を記述したい場合には
"&amp;"などとしてやる必要があるわけです。

以下余談。属性値が名前文字以外のものを含む場合、
属性は常に属性値リテラルを用いて記述する必要があります。
"&"や";"は(HTMLでは)名前文字ではないので、
<a href=hoge.cgi&amp; >といった書式は禁じられています。

しかし、仮にSGML宣言をいじって"&"と";"を名前文字に含めたとすれば、
href=hoge.cgi&amp; の属性値は「hoge.cgi&amp;」(∵属性値として記述されている)
href="hoge.cgi&amp;" の属性値は「hoge.cgi&」(∵リテラルとして記述されている)
ということになるわけです。了。

どうでもいいけど、2chは &amp;amp を &amp; に変換するから
&amp;amp; と入力すると ; が余分になるよ。

>>730
別に余分になってないけど。ブラウザがおかしいのでは？
ソース見てみれ。最近2chは基本的に&を全く変換していない。

"<"">"を変換してる以外は、"&ほげほげ"みたいな部分も
"&ほげほげ"のままで処理してる。

>>731
" くらいは処理して欲しいな。

>731
IE他で見たら確かに変換してなかったわ。
かちゅ〜しゃが勝手にやってたのか…。

>>732
地の文でわざわざ&quot;にする必要はないと思われ。
というか、ほんとは">"もそのままで構わない。

このスレ読んだ。勉強になった。

>>725
いや、それは拡張子なしのファイルをtext/htmlにするやつでしょ？
拡張子なしのファイルの文字コードをshift_jisにするには
どうしたらよいのかということなのです。
ForceType text/html; charset=shift_jis
でいいのかなあ

>>736
HTTPヘッダをtext/htmlで出力するわけだから、それでいいような気がするんだけど。
人柱よろしく(ｗ

>>734
いやいや、かちゅ〜しゃのスキンとかで
Javascriptを使いたい時にはそのほうが都合がいいものでして。

imgのheightとwidthってstrict？

>>739
うん

ありがとう。

>>737
736でないけどやってみた。
文字化けはしない。でもさ。
どうせなくても文字化けしないんだから
あってるのかふぉうか不明。
ハトマルはどうやってるんだろ？

>>739
精神的にはStrictでないかも。とりあえずISO-HTMLにwidth/heightはない。

>>742
utf-8とかの指定無しじゃまず化けるような(MacIE5だけか？)コードで試してみたら？
じゃなきゃmetaにわざと違うコードを指定して、生のヘッダの記述が優先されるか確認するとか。
的外れだったらスマソ。

>>742
単に拡張子じゃないの？

〜/html/hatomaru.html.ja.jis
〜/html/hatomaru.html.ja.sjis
〜/html/hatomaru.html.ja.utf-8

と云う風に。後はHTTPのAccept-Encodingヘッダで振り分ける。

Accept-EncodingじゃなくてAccept-Charsetだった、ｽﾏﾝ。

>>742
Proxomitron 使ってれば Open Log Window で HTTP ヘッダ確認できるよ。

拡張子なしのファイルだとローカルの確認が面倒
html4.01ならいいけどxhtmlでかいたファイルは
ローカルで拡張子なしだとIEで見てもソースが見えるだけ
拡張子ありでいいよねえ。？

>>747
>>722はローカルでの確認なんか拘泥していないってことでしょ。
君には関係無いから別にそれでいいよ。

……つうか遡ってみると話がだんだんずれてるし。

>>742
あとネスケ 4.x (6.x ではダメ)で開いて
View - Page Info (表示−ページ情報だっけ？) とかやると、
文字セット指定がある場合はそれが表示される。

>>739
小さい画像にheightとwidth指定していると、
画像がロードされるまでAltが読めないというなかなか本末転倒な結果に。
今日久しぶりに体験した。

content negotiation を有効にしておけば、
.jis とか付いていたら charset=iso-2022-jp を付けたりする

しかし、.euc や .sjis はデフォルトでは提供されていないので
追加する必要があったような

>>750
画像ロード中に代替テキストが提供されてもいいような気は確かにするけど、
基本的に画像表示可能な環境に提供される必然性は無いような気がしないでもない。

>>752
リンクが切れてることだってあるし、
ファイルが壊れてることだってあるじゃんよ。

>>753 なるほど。なんか解らなくなった。難しいね。

>>728
古い方が必ずしも「前」とはいえないと思う。
掲示板のつくりにもよるけど、この場合は「次」だろうし。

>>755
掲示板がどう表示していようが、
時間の経過としてはほぼ間違いなく
「以前」に書いた文章だと思うので
「前述」かと思いますが、いかが。

>>753
代替テキストをどうレンダリングするかはブラウザの問題。
と言うより、その二つの例は著者のミスであって、
strictがどうこうという問題ではないと思う。

>>756
時間としてじゃなく、全コンテンツをなめるように見せたいときの
リンクタイプはどういうのを指定したらいいでしょう？
うーむ。

そもそも掲示板にありがちな「次の10件」という書き方がおかしいと思うのだが。
普通に考えれば「前の10件」じゃないのかあれは。

>>758
うんうん。
しかも時々"前の10件"が過去の10件を表わしてたりするサイトがあるからわかんなくなる。
"過去の10件" だと間違いないよね。

＞"過去の10件" だと間違いないよね。

そうですね。これが一番。

>>755
ちなみに、リンクタイプはやはり時間順で「過去=prev」「未来=next」が良いと思います。
start/lastとの対応関係を考えたときにも矛盾がない。

>>757
あ、前述・後述の話か。ｽﾏｿ。

でもどっちにしろ、「読む」順番ではない
基準にしないと、stricではなくなると思う。
「書き込み」順があるのだからそれに沿って
時間を基準にすればいいと思いますよ。（掲示板の場合）

>>759
前、だけだと何を基準にしてどちらに向いて
前なのかわからないしね。

>>761
×あ、前述・後述の話か。ｽﾏｿ。
○あ、前述・後述の話じゃないのか。ｽﾏｿ。

ツリー型の掲示板で新着レスがageになるやつだと、
必ずしも時系列でソートされているとは限らないのでは？

ツリー型のことを全く考えてませんでした。

ツリー型なら「次のページ=next」で良いか…。

ForceType text/html; charset=shift_jis
でなく
ForceType "text/html; charset=shift_jis"
でした
"ぬけてました
お詫びして訂正いたします。

>>763
それでも各スレッドの最新の書き込み順
になっているのは変わりない。
２ｃｈみたいにスレッドに書き込みが
あるとが上がってくるという動作は、
その最新の書き込みの日時が基準だと思う。
それなら、その日時を基準にすべきかと。

更新履歴の書き方について訊きたいんですけど。

02.05　なんたらかんたら
02.01　あんにゃもんにゃ
01.20　ちんたらまんたら
・・・

のように、日付と簡単な更新内容がペアになったものの場合、
どうマークアップすべきでしょう。
定義リストにしてしまっても良いのでしょうか。

>>767
いいんじゃねーの。簡単な更新ない様（1行程度）ならulでもいいと思うな。
日付けと文章は：とかの記号で分ける。

dt {float:left;width:20%;}

<dl>
<dt>02.05</dt>
<dd>なんたらかんたら</dd>

<dt>02.01</dt>
<dd>あんにゃもんにゃ</dd>

<dt>01.20</dt>
<dd>ちんたらまんたら</dd>
</dl>

>769
dt が 20% を超えたらみっともないことになりそうだが，
それ以上に dd が折り返したらもっとみっともないことになりそうな．

>>770
いや、そこに突っ込まなくても．．．。
そこらは臨機応変にやってくれ。

ttp://www.remus.dti.ne.jp/~a-satomi/updatelog.html
こんな感じ？

>>772
んで、
http://www.remus.dti.ne.jp/~a-satomi/nikki/2001/12b.html#d18n03
が、その説明。
とはいえ、%指定よりもemやexで指定しないとダメだね。

貼るの忘れてた。>>650辺り関連。ためになります。

http://kanzaki.com/docs/html/dtf.html

かんざきさんの日付の記事、反響大きいなあ。

>>768-773
ありがとうございます。あの後ウトウトして、そのまま寝てしまいました。
マークアップはdlでいいとして、
floatで1行にする方法についてなんですが、
dtにclearも指定しといた方がいいですよね？
dtボックスの方が高くなるケースを考えると。

>>774
ためになりました。

>>769
これ追加しておいて。
dd {margin-left:21%;}

dtが折り返されたら最悪なんで
white-space:nowrapもいるかも。

　　　dtにブロック入れたいよー