Strict-HTML スレッド24

**Name_Not_Found** · 04/10/02 22:19:38

Strict な HTML について語るスレッド 24回目
W3C 信者もそうじゃない人も投稿歓迎。でもHTMLの基礎知識は欲しいね。
sage進行推奨。

* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
* XHTML 1.1, XHTML 2.0, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。

Strict-HTML スレッド23
http://pc5.2ch.net/test/read.cgi/hp/1094311630/

過去ログ・関連スレ >>2
勧告等・その他 >>3

**Name_Not_Found** · 04/10/14 16:42:51

dfnは索引を自動生成するようなのを念頭に置いて作られたのかな。

**Name_Not_Found** · 04/10/14 17:15:15

>>214
dfn は「それが何らかの定義語」で有ることは明示出来ても、
どんな定義か、を明示する方法が定められていないので、明示出来ません。
引用元であることは明示出来てもどの引用文の元かは解らない cite みたいな感じです。

用語集などを作る場合は、>>216 みたいな感じになります。

**Name_Not_Found** · 04/10/14 18:44:35

>>218
定義語って何？辞書に載ってない。

そもそもdfn使うメリットほとんどないよな。
っていうかそもそも正しいマクアップは視覚UAにはｍリットあからさまではないよね。
音声とかロボ系にはいいけど、視覚のためにつくってるサイトで他のUAについての
考慮で作業を増やすのってビジネスとしては許されないよね。すくなくともうちでは。

っていうかこのスレで現実ばなっししても無意味だったごめん。
まあHTMLをPDFのようにしかつかわない俺にはおまいらの意見など耳に届かないんだよな。

しかし、PDFがもう少しユーザｎ優しければなぁ。
そもそもHTML以外でHTMlレベルの資格レベルと使いやすさと速さは無理だね。
PDFはいちいち起動時間があるし。そもそも入ってるかわかんねえしｗｗｗ

っていうかHTMLがスタンダードな時点で不思議だと思わないか？
だってHTMLは視覚計に的を絞ってるものではないのに、
視覚計に的を絞ったコンテンツに一番使われてるのがHTMLｗｗｗｗｗｗｗｗｗｗｗｗｗ

ｆｇｈｋｓｈフォジャンｆｄ；雄ｇじゃｆｄん；あｊんｄｆ；ほあｊｈんがへｆｊうぇｊｈうぇｊｔｈうぇｊｔｈｗｊｈ

**Name_Not_Found** · 04/10/14 18:59:52

>>219
どうしたんだ、おちつけ。

**Name_Not_Found** · 04/10/14 23:25:56

>定義語って何？辞書に載ってない。
そこでdfn要素の出番ですよ。

**Name_Not_Found** · 04/10/15 00:58:29

XHTML 2.0の話はここでいいのかな。

<ul>
　<label>hoge</label>
　<li>huga</li>
　　　　：
　　　　：
</ul>

<dl>
　<dt>hoge</dt>
　<dd><ul>
　　<li>huge</li>
　　　　　：
　　　　　：
　</ul></dd>
</dl>

この二つで物凄く混乱しそうなんだが、明確な線引きってどうすればいいんだろ？

**Name_Not_Found** · 04/10/15 01:27:33

>>222
そもそもHTMLにそんな厳密さはいらない。
適当にいけよ。

**Name_Not_Found** · 04/10/15 01:40:40

>>222
今まで通りに使い分けて、後からlabelを付加する(気持ちで使う)んじゃ駄目なの。

**214** · 04/10/15 04:23:59

>>215-221 さんくす

やっぱリスト使うしかないのか…

俺が考えたのは…(妄想だけど)

<dfnc id="hoge">ｾｯｸｽの2ch語</dfnc>を<dfn rel="hoge">ｾｯｸﾙ<dfn>といいます

って感じ。属性はいい加減につけたから気にしないでください
dfncはdfn contentの事。ID振ってdfnの属性でそれを参照する
これなら明示できる。

XMLですかそうですかすみません

**Name_Not_Found** · 04/10/15 08:47:28

>>222
状況によっては、

<hn>hoge</hn>
<ul>
<li>huga</li>
:
</ul>

**Name_Not_Found** · 04/10/15 09:18:29

>>225
HTMLでにたような事をやりたければ、

<a rel="Glossary" hraf="#hoge"><dfn>hoge</dfn></a>
…
<dl><dt id="hoge">hoge<dt><dd>hogeとは……</dd></dl>

こんな感じになるかと。
更に頑張りたい人はscriptとかでリンク先のddの内容をポップアップ
させるとか。

**Name_Not_Found** · 04/10/15 14:42:32

その前にhrafを何とかした方がいいな

**Name_Not_Found** · 04/10/15 16:54:18

>>227
MS的には、
ﾅﾝﾃﾞ iframe ﾂｶﾜﾈｴﾝﾀﾞﾖヽ(`Д´)ノ
って話なんだろうよ。

**229** · 04/10/15 16:54:41

ごばく

**227** · 04/10/15 20:24:43

>>228
イヒッ。

…ごめんtypoです。

**Name_Not_Found** · 04/10/16 17:46:08

lintに繋がらん・・・・

**Name_Not_Found** · 04/10/17 00:13:10

>>232
だからなんだよ？
うわごとをいちいち書き込むんじゃねえよ

**Name_Not_Found** · 04/10/18 22:07:22

>>233
てめーもだよカス

**Name_Not_Found** · 04/10/19 16:03:31

とりあえず「lint」なんていう意図不明な略し方はやめてほしい

**Name_Not_Found** · 04/10/19 18:07:57

**Name_Not_Found** · 04/10/19 20:59:27

整形済みテキスト(pre)には、
非等幅フォントを指定すべきでは無いんでしたっけ？

**Name_Not_Found** · 04/10/19 21:30:51

>>237
用途にもよるけど、
例えばプログラムソースとかだったら、
等幅の方が見やすいよね。

**Name_Not_Found** · 04/10/19 21:43:14

仕様書にそういうことが書いてあるかどうか、という話題ではなくて？

**Name_Not_Found** · 04/10/19 21:43:41

というかそれはStrict-HTMLスレの話題じゃないんじゃ？

**237** · 04/10/19 22:08:00

>>239
どこかで読んだ記憶があるんですよ。

>>240
複数行にわたるアスキーアートのマークアップとかかわってくるんです。

**Name_Not_Found** · 04/10/19 22:10:34

確か仕様書にも「このようにレンダリングすることが望ましい」って記述はあったような…

**Name_Not_Found** · 04/10/19 23:47:27

>複数行にわたるアスキーアートのマークアップとかかわってくるんです。

マークアップは<pre>で囲むだけだから、フォントが等幅かどうかは関係ないだろう。
表示上の問題だったらそれはCSSの話であって。

**Name_Not_Found** · 04/10/19 23:51:16

ぶり返しの予感

**Name_Not_Found** · 04/10/19 23:53:28

> 非等幅フォントを指定
> 複数行にわたるアスキーアートのマークアップ

マークアップとフォントファミリの指定は関係ない

**Name_Not_Found** · 04/10/20 00:07:47

もっと目新しい話題ないの～？

**Name_Not_Found** · 04/10/20 00:10:00

そういや、ここらの人はHTMLの国際化には無関心なんだろか。
ttp://www.w3.org/TR/2004/WD-i18n-html-tech-lang-20041015/

# Webの英語化スレで持ち出しても反応なかったしな。

**Name_Not_Found** · 04/10/20 00:28:04

俺は xml:lang と (元ページと違う言語へのリンクの場合) hreflang を
指定してる程度かなぁ。

引用は別にして、自分の文章が書ける言語って日本語だけだし。

**237** · 04/10/20 00:40:29

>>243 >>245
preが等幅で整形された文章を前提にしているのなら、
（ＭＳＰゴシックで表示しなければならない）アスキーアートを
preでマークアップすることがそもそも間違いなのではないかと。

**Name_Not_Found** · 04/10/20 01:02:09

>>249
>preが等幅で整形された文章を前提にしている

pre がどのフォントファミリで描画されるべきであっても、
要素の意味合いは「整形済み」であることには変わらないだろ。
どうしても気持ち悪いなら SVG でも PDF でも好きに使え。

**237** · 04/10/20 01:37:25

>>250
preの「整形済み」の範囲なんですよ。

The DTD fragment above indicates which elements may not appear within a PRE declaration.
This is the same as in HTML 3.2, and is intended to preserve constant line spacing and column alignment for text rendered in a fixed pitch font.
Authors are discouraged from altering this behavior through style sheets.
　　　　　( http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#h-9.3.4 )

だそうなので、仕様書が「The PRE element tells visual user agents that the enclosed text is "preformatted".」でいう
「"preformatted"」は等幅を前提にした「整形済み」なのではないかと。

pre要素の意味合いが「等幅で整形済み」であれば、
非等幅フォントの為のアスキーアートをpreでマークアップするのは間違いですよね。

**Name_Not_Found** · 04/10/20 01:42:09

>and is intended to preserve constant line spacing and column alignment for text rendered in a fixed pitch font

「あとこの要素は等幅フォントとか一定の行間とかで表示される予定ですよ」と俺には読めるが。
つうかその要素（文章でもAAでも）がMS P ゴシックで表示されなきゃならんのならHTMLの範疇じゃないだろ。

**Name_Not_Found** · 04/10/20 02:45:02

素朴な質問

「strictの本質って何？」

これをいきなり思った。それで「ソースレベルでの見栄えと構造の分離」だと思った。
しかしそれの本質って何よ？って思った。「ソースの再利用性を高める」って思った。
何か違う気がした・・・・

元々は、アクセシビリティをあげることとstrictHTMLに仕上げることをごっちゃにしてるやつに
「strictの本質はアクセシイビリティとは関係ない」って自問自答したのがきっかけ。

おまいらstrictの本質ってなんだと思う。その答えの本質。さらなる本質も教えてくれ。
ageて広く意見を求めるごめんよ。

**Name_Not_Found** · 04/10/20 06:10:22

>>253
平日のそんな時間にageても(ry

strictで済んでいればいいよな
原理主義者はstern
いかんせん仕様書は読者の解釈に幅を持たせているから宗教的思想が生まれる

で、ﾙｰﾙはしっかり守りましょって事だろ? > strict
仕様書にｱｸｾｼﾋﾞﾘﾃｨへの配慮が必要だと明記してあればstrictとｱｸｾｼﾋﾞﾘﾃｨは関係がある

HTMLに限った話では無いけどね

仕事逝ってきまつﾉｼ

**Name_Not_Found** · 04/10/20 08:22:18

>>253
本質なんて、そんなのどこにもないよ。
だからみんな言うことにバラつきがあるのさ。

**Name_Not_Found** · 04/10/20 08:32:23

>>251
じゃあ、ナンバリングして表示される予定の ul の小要素の li を
CSS の display プロパティで inline にしたりするのはどうなのよ?

一般的にナンバリングされるliを、CSS でそうしない事によって
HTML側のマークアップは影響うけないっしょ?

preは「等角フォント整形済み文章」 "ではなく" あくまで「整形済み文章」(等角フォントで表示予定)
かと思われるが?

>>253
>何か違う気がした・・・・
何が違うか自分で考えれ。

定義の話なら兎に角、感性の話をして荒れるだけ。
っていうか「僕の考えたstrict」はいままで散々荒れた話題。

少なくとも「こう思う」「違う気がした」ソースをW3Cの文書から
出してこないと水掛け論にしか成らない。

**Name_Not_Found** · 04/10/20 13:34:57

AA自体、文字本来のありかたを外れた裏技の披露にほかならないのであるから、
その表示がpre本来のありかたを外れた裏技によってなされたとしても気にするべきでは
ないのではあるまいか？

**Name_Not_Found** · 04/10/20 14:48:44

AAなんてものを表示させることは想定されてないからな、そもそも。
MathML同様、独自にDTD作ればっちゅう話や。

**Name_Not_Found** · 04/10/20 15:22:44

・最終的には独自にDTD作るくらいなら XHTML+SVG で、
・HTML のみ解釈できる UA を対象にしたいなら object 要素を使って
　PDF なり、画像データを代理メディアとして指定する、
といういつもの結論に落ち着きそうな予感。

**Name_Not_Found** · 04/10/20 18:57:15

>>257
>文字本来のありかたを外れた裏技の披露

文字を使って表されている以上テキスト（文章）であるし、
改行位置や空白挿入位置などが決まっているから整形済み文章と言える。

**Name_Not_Found** · 04/10/20 20:19:42

>>247
ちなみに、主な内容は以下のとおり。

文書の記述言語の宣言
・文書を記述する主要な言語が1つだけなら、常にhtmlタグで(テキスト処理方法を示す)デフォルト言語を指定すべし。
・メタ情報としての主要言語の宣言には、HTTPヘッダやmeta要素でContent-Languageを使用すべし。
・(テキスト処理方法を示す)デフォルト言語の指定にはContent-Languageを使用すべからず。
　メタ情報としての主要言語の宣言には、lang属性を使用すべからず。
・bodyタグで文書の記述言語を指定すべからず。

複数の主要言語のある文書
・複数の主要言語がある場合、Content-Languageを用いるのなら、言語をカンマ区切りで列挙すべし。
・複数の主要言語のある文書では、htmlタグに言語を1つ指定するか、それとも何も指定しないようにすべし。
・複数の主要言語があるときは、なるべく高い階層で分割し、各ブロックで言語を指定すべし。

言語の切り替えの宣言
・文中の言語の替わるところでは、lang/xml:lang属性を指定すべし。

言語の指定
・HTMLではlang属性、text/htmlのXHTML1.0ではlang/xml:lang両方、*/(xhtml+)xmlのときはxml:langのみ指定すべし。
・言語を指定する属性値についてはRFC 3066に従うべし。
・言語コードが2文字・3文字の両方ある場合、2文字のISO 639コードを使用すべし。
・簡體中文、繁體中文にはそれぞれzh-Hans、zh-Hantを使用すべし。

リンク先の言語の指定
・他の言語のリソースにリンクする場合、hreflang属性とCSSで言語の表示を考慮してみるべし。
・hreflang属性とCSSで言語マーカーを生成するとき、その内容に国旗のアイコンを使用すべからず。

**Name_Not_Found** · 04/10/20 21:15:39

>>260
複数行AAまでも「整形」の範疇として想定されているのであれば
特定フォントの文字幅に依存する表現についても規格上便宜を図るはず。

**Name_Not_Found** · 04/10/20 21:29:02

>>261
国際化を特に意識してた訳じゃないけど (日本語しかおれしゃべれないし)
仕様に沿ってxml:lang属性を設定してた結果、概ね守れてるみたい。

個人的に興味深いのは
>hreflang属性とCSSで言語マーカーを生成するとき、その内容に国旗のアイコンを使用すべからず。
かな。理由も知りたいからあとで原文読んでみます。

**Name_Not_Found** · 04/10/20 21:39:53

>>263
理由はとても単純で、国旗が表すのは国であって言語ではないから。
複数の国で同じ言語が使われてたり、一つの国で複数の言語が使われていたりする、と。

**Name_Not_Found** · 04/10/20 22:23:49

個人的にはhreflangはあんまり書きたくないな。
コンテントネゴシエーションが今一普及してないから微妙だけど、
object要素のtype属性と同じで、言及元のHTMLで
何かを特定するのはなんとも気持ち悪い。

**Name_Not_Found** · 04/10/20 23:03:56

>>264
> 国旗が表すのは国であって言語ではない
ちょっと考えてしまいましたが納得です。
ちなみに漏れは CSS で言語を示してます。

**Name_Not_Found** · 04/10/20 23:43:24

>>265
確かに。メンテナンスも煩雑になるしね。
まあそれを言うと、リンク切れなんかも同質的な問題なのかもしれないけど、
みんなに恒久的なURIを保持してもらうのも無理な相談だよなあ。

**Name_Not_Found** · 04/10/21 00:11:00

しかし、リンク元でリンク先の言語やメディアタイプの情報が提示されていれば、
無駄なアクセスを防げるって利点も捨てがたい訳で。

人間の事だけ考えれば(パケットとか帯域の事を考えなければ)、
人間がすぐさまページないのリンクを片っ端から開き始めると言うケースは
少なそうなので、空き時間にリンク先に接続してHTTPヘッダを取得して
動的に(DOMかなにかで)HTMLに情報を追加するというのが理想かも。

**Name_Not_Found** · 04/10/21 01:13:34

それはリンク元が(DOMで追加にしても)ソースレベルで行う事ではなくて、
UAが利用者へのナヴィゲーションの一部として行う事では?

例えばリンク先への移動の予備動作(一般的にはマウスオーバーイベント)時に
ユーザーに「英語が主体の RDF 文書です」という情報をツールバーにでも
表示すればいい、と言う意味で。

**Name_Not_Found** · 04/10/21 07:02:58

>>262
要するにW3Cに「AAのことも考えてくれよ！」ってことか？ｗ
等幅だろうが等幅じゃなかろうが記述される文字列は変わらないわけで、
じゃあとは見栄えの問題なんだからCSSでやれよ、ってのは散々既出。

**Name_Not_Found** · 04/10/21 08:39:27

そもそも相手がそのAAに適したフォントを持ってるとは限らないので
等角とか、等角じゃないとか、そんな事は情報としては小事。

例えば2Byte文字混じりのAAは、1Byte文字のフォントしか持ってない環境では
どうやっても再生できない。
画像(含むSVG)にするか、PDFみたいにフォントを埋め込むのが妥当。

**Name_Not_Found** · 04/10/21 09:33:17

>特定フォントの文字幅に依存する表現

だからこれはHTMLの範疇じゃないと何度言えばわかるんだ

**262** · 04/10/21 12:01:02

>>270
>>272
複数行AAまでも「整形」の範疇として想定されているのであれば
特定フォントの文字幅に依存する表現についても規格上便宜を図るはず。
なのにそういうことをしていないということは、つまり、そんなものは
整形済文書として想定していないということ。ゆえに、>>260の言うことには
賛同できない。

**Name_Not_Found** · 04/10/21 12:10:30

つーか HTML の pre 要素って等角とか、プロポーショナルとかじゃなくて、

「この区間は空白文字、改行文字、TAB文字も意味があるので保持して下さい」要素

の事なんじゃないかなぁ。

**Name_Not_Found** · 04/10/21 13:57:50

>>273
んなことを言い出したらHTMLの規格は（ネット上の）全ての文化・スラングを考慮せなならんわけだが。
この場合「整形済み」の条件をいくつか満たしてるからpreでマークアップするのが適切、って話だろ？

あと他人の言葉引き出さないと自分の考え説明できない、ってのはどうかと思。

**253** · 04/10/21 16:36:27

私は>>253です。>>254-256
何か勘違いしてるけど、俺が言いたいのは「何故」strictなのかってこと。
すなわちstrictだるゆえんは何だと。strictを広める理由こそがstrictの本質に一番近いものなんだよね。

w3cは何のためにstrictを勧告したのか？
ソースレベルでの見栄えと構造の分離のため。
では何故そこに至ったのか？
HTMLソースの再利用性を高めるため
「本当にそうなの？再利用性なんて本当にグローバルに重要なこと？個々の話ではないの？
　もしそれだけなら、strictの必要は全くない。CSSだけできればいいわけで
　いちいち全員にHTMLを論理的に仕上げることを薦める必要がない。
　個々がCSSをうまく使ってHTMLの再利用性を高めればいいだけ。」

ではもう一度
w3cは何のためにstrictを勧告したのか？
ソースレベルでの見栄えと構造の分離のため。
では何故そこに至ったのか？
わからない・・・orz

誰かわかる人いないの？何故strictにHTMLを仕上げることを薦めるのよ？
何故他人のプログラムのアルゴリズムに口をはさもうとするのよ？
！？ユーザスタイルシートか。
でもそんなマニアックなもののためにstrict広めるの？
アクセシビリティ・ユーザビリティの向上をユーザ自身で可能にするため？

しかし仕様書のどこにもstrictはアクセシビリティのためにあるなどとは・・・
HTMLの再利用性についてはグローバルではユーザスタイル以外に影響を与えられない・・

よくわからんなw3cの行動は・・・やはり自分達に自身がなくて「勧告」ってことなのかね。いつまでたっても仕様書なんて出てこないのね

**Name_Not_Found** · 04/10/21 16:51:28

> w3cは何のためにstrictを勧告したのか？
W3Cは"Strict"など勧告していない。

**Name_Not_Found** · 04/10/21 17:00:45

統一された規格にきっちりしたがってモノを作る行為自体に陶酔しちゃう
タイプの人間って（漏れもそうだけど）結構いてさ。
他の分野（とくに工学系）でもそういう傾向って少なからずあって、
規格統一とか一応唱えたりするじゃん。ただ、資本主義社会で物作りの
ベースが商業の一端になるゆえに、自由競争の礎となる独創性・特殊性と
相反しちゃって、結果として単なる理想、絵に描いた餅にしかならないけど。

で、ティムたん自身か、もしくはその周辺の結構チカラある人物の中に
そのタイプの人間がいて、
「あぁ、規格通りのコードを書いている私は今、確実に美しいぃ！」
ってオナニーするために暴走して、strictという規格をやっつけてしまった。

と妄想してみるテスト。

**Name_Not_Found** · 04/10/21 17:03:52

>>276
てか君の自問自答の中の「再利用性」が何なのかよくわからん。
構造に関する情報を取り出しやすければ再利用性が高くなるのは
当然だとおもうんだが。CSS見たって表示以外の利用にはほぼ使えないじゃん。

**Name_Not_Found** · 04/10/21 17:04:05

strictという規格ってなに？

**Name_Not_Found** · 04/10/21 17:07:29

>>276
論理的に記述してあれば、ソースレベルで見て意味が理解できるだろ。

<h1 style="color:#f00;">ふんにゃか</h1>

<font size=+5 color=red>ふんにゃか</font>

上は見出しであることがソースで見てわかるけど、下はわからん。
明示的に意味が記述されていれば、色々な応用がきくのはわかるだろ？

見栄えと構造の分離は副次的なもんだ。本質じゃない。

**278** · 04/10/21 17:11:49

>>280
strict な書き方、ですかね。

**Name_Not_Found** · 04/10/21 17:12:35

>>278
まあ、timbl自身は現実的な人だと思うよ。
そうでなかったらted nelsonと同じ結末を迎えていたでしょう。

**276** · 04/10/21 17:27:39

>>279
再利用性ってのはHTMLの話ね。
>>281
>論理的に記述してあれば、ソースレベルで見て意味が理解できるだろ。
それは個々の満足であって全員に薦める必要性はない。
ユーザスタイルなどのためという一点しか論理的であるソースの利便性がない（グローバルなレベルでの利便性ね）。
その利便性だけのためにstrictを作った？そんなことないだろ。

そもそもstrictをすすめるやつっての２ちゃんにわんさかいるけど、誰一人
その本質を答えられないだろ。本質を知らないのに何が
「それはstrictじゃないからよくない」
なんだろうな。「何故strictなのか」を知らないのに広めようとするなよ。

**276** · 04/10/21 17:28:15

ごめんageてしまった。ごめんなさい。

**276** · 04/10/21 17:33:27

>>276
自分で読んだが何か違うな。
論理的なマークアップは問題ないんだった。それは昔からのHTMLの規格だからな。
まあ人に薦める必要性は微妙だけど。

見栄えと構造の分離をする意味だった。まぁナンデモいいか。

**279** · 04/10/21 17:33:51

>>284
いやだから、「再利用」ってどういう風に利用すること想定してる？
よく挙げられる例だと、例えば文書群の<hn>を抜き出して目次を作る
なんて話があるけど、ちゃんと構造をマークアップしてないと
こういう再利用ができないだろ？

>個々がCSSをうまく使ってHTMLの再利用性を高めればいいだけ

の意図がよくわからんのよ。

**Name_Not_Found** · 04/10/21 17:48:02

>>284
例えば、漏れは某ディレクトリ型検索サイトのHTMLを取得して新着サイトをリストアップ、キーワード別に分類するようなソフトを書いたのだが、そのサイトがテーブルレイアウトのページでしか情報を提供してなかったのよ。
で、乱れ飛ぶtdタグと睨めっこをしながらフィールドを切り分け。当然ValidなHTMLでも整形式のXHTMLですらないから文字列として正規表現で切り分け。
しかもマークアップもたまに変則的なのが混ってたり、自然言語を解析しないと分らない記述や、酷いときには視覚に頼らないと分らない記述があって完全には解析できてない。

こういうソフトを作るのは一部の人間とはいえ、全てのサイトがせめてValidであれば検索エンジンやブラウザはもっと便利な機能を提供できる。
比較的ちゃんと書かれたものが多いRSSや、形式がある程度定まっている2chのdatファイルを処理するソフトはIEなんかよりずっと便利な機能を提供してるのが良い例。

**279** · 04/10/21 17:51:04

>>287の続き
あーもしかして既にあるコンテンツを著者が書き換えて
見栄えを変えたりするようなケースの事言ってたのかな。
HTMLの再利用性っていうと、閲覧者やUAが単純表示以外の
用途に使う時の使いやすさを指すことが多いと思うんだけど。
そっちは論理構造をちゃんとマークアップしてるかどうかで全然違うよ。

**Name_Not_Found** · 04/10/21 18:00:02

>>284
>それは個々の満足であって全員に薦める必要性はない。
個々って誰よ？製作者か？閲覧者か？

**Name_Not_Found** · 04/10/21 18:06:26

途中で送信しちまった。
>>288と重なる部分もあるが、論理的構造がしっかりしてると機械にも
わかりやすいってことだ。strict思想ってのは閲覧者（UA）の都合であって
製作者の都合じゃない。
strictなサイトはgoogleでもばっちり検索がヒットするだろ。

何度も言うが、見栄えと構造の分離は論理的なマークアップをした結果に
しか過ぎないことであって、それが本来の目的ではない。

**Name_Not_Found** · 04/10/21 18:08:45

> strictなサイトはgoogleでもばっちり検索がヒットするだろ。
これは流石に

**Name_Not_Found** · 04/10/21 18:13:54

>>292
すまん。言い過ぎた（；´Д｀）
でも、検索エンジンに拾われやすいのは確かじゃないか？

**Name_Not_Found** · 04/10/21 18:21:29

まぁ、確かにSEO業界ではStrictなマークアップを推奨してる人が多いな。

**276** · 04/10/21 18:36:49

ごめん自ら話をずらしてしまったのだ。
再利用性とか忘れてもらってもいいかも。

strictの以前から段落はpとか見出しはhnとかそういう規格だったね。
strict云々とは無関係な方向へ走ってしまったorz

strictへの変更点である見栄え属性を排除すること、いわゆる
「HTMLソースから見栄えに関するものを排除する」
っていうのが結局本質なのかね？でも上で誰かがそれは副次的なものってレスしてたっけ。

で、strictって何のために考案されたのかね？
論理云々はstrict以前のHTMLの昔からの仕様だからおいといて。（論点を右往左往させてしまって申し訳ない）

**Name_Not_Found** · 04/10/21 18:42:07

strictって見栄えと構造の分離ではなく論理的なHTMLへの原点回帰なんじゃないのか。

**論理空間構築派** · 04/10/21 18:43:21

ストリクターにも派閥があることをお忘れなく。

**Name_Not_Found** · 04/10/21 18:46:04

>論理云々はstrict以前のHTMLの昔からの仕様だからおいといて。

いやおいといちゃ駄目だろ。
以前のHTMLだと論理的な要素とそうでないものがごっちゃになってたので、
規格を整理して論理をよりきっちりと表せるようにしたのが
strictなんじゃないの。(完全ではないだろうけど)

**Name_Not_Found** · 04/10/21 18:48:33

STRICTのDTDが別にあるのはNNとかIEが独自拡張して
HTMLがゴチャゴチャになっちゃったからだからな。
後方互換性のためにTraditionalも残しておいてあるだけで。

**Name_Not_Found** · 04/10/21 19:01:15

>>295
論理構造を正確に記述するのがstrictの本質だと思うがな。
そうした記述をやりやすくしたり、記述された構造を利用しやすくするための
一手段として、見栄えを別ファイルに分離するという規格が考案された。
そういう意味では分離する事自体は副次的と言えるんじゃないかな。

**295** · 04/10/21 19:04:26

>>298
というと、論理的にマークアップさせUAに構造を伝えるのが目的なの？

＞>論理云々はstrict以前のHTMLの昔からの仕様だからおいといて。
これは昔からHTMLある程度論理的にマークアップするものだったからっていう意味。
昔のHTMLでだって今と同じレベルの論理構造を表せるでしょ？
何故見栄え属性を切り捨てる必要があったのかな？って。
以前は論理～見栄え
strictは論理だけ
っていう感じだけど、見栄えを切り捨てる必要性は？って思った。
そこらへんは個々にまかせればいいのにstrictDTDには見栄え計のものが存在しない。
半ば強制的に（そうでもないけど）見栄えをHTMLに含めるなといってるのは何故だろう。

**262=273** · 04/10/21 19:21:10

>>275
なかなか伝わらないね・・・

考慮していないとは言っているが、考慮しろと言ってるわけじゃない。

AAなんぞは裏技なんだから、「こうあるべき」という厳密な基準にあてはめようとするのは
自己否定だと言いたいの。わかる？

**297** · 04/10/21 19:21:10

time flies like an arrow and 297's out of the world

**Name_Not_Found** · 04/10/21 19:25:44

>>301
>これは昔からHTMLある程度論理的にマークアップするものだったからっていう意味。
>昔のHTMLでだって今と同じレベルの論理構造を表せるでしょ？

ある程度はできるけど、全く同じは無理でしょ？
HTML3.2と4.01比べるだけでも結構色々変わってるよ。

>以前は論理～見栄え
>strictは論理だけ
>っていう感じだけど、見栄えを切り捨てる必要性は？って思った。
>そこらへんは個々にまかせればいいのにstrictDTDには見栄え計のものが存在しない。

役割が違ってたら違うものに任せるってのは自然な発想だと思うけどなあ。
個々にまかせればいいのにったって、一つのファイルになってたら
利用者はいちいち必要ない部分まで全部読み込まなきゃならないじゃん。
別ファイルになってれば、必要があれば両方読み込めばいいわけで、
それこそ個々に任せるってことだと思うんだけど。

**Name_Not_Found** · 04/10/21 19:31:41

>>301
>半ば強制的に（そうでもないけど）見栄えをHTMLに含めるなといってるのは何故だろう。
HTMLは文書を意味付けるものだから。
見栄えなんて考えちゃいないのですよ。

**237** · 04/10/21 19:34:14

AAがHTMLの範疇でないというのは承知してます。
でもAAをHTMLでマークアップしないといけない状況は往々にして出てきますよね。
なにせAAこそwebで発展して技術だからです。

さて、そのときにAAのマークアップはpre,p,div,etcのどれが適切なのかということなんですが、
結局このスレの意見としてはpreで良いということになるのでしょうか。

**Name_Not_Found** · 04/10/21 20:00:52

リー博士は昔からセマンテックWEBを夢見てたから、
HTMLが視覚UAだけの為に拡張されるのは許せなかったんだろうな。

モジュール化したほうがメンテナンス楽だしね。

**Name_Not_Found** · 04/10/21 20:02:11

「このスレの意見」なんてものを要求されても困る。俺はpreでいいと思うが。
「空白や改行文字を含んだ謎の文字列」を伝えられれば
HTMLの役割は果たせた事になるんじゃね？それ以上の要求は無理、
表示は見る人が勝手にどうにかするってことで。

**Name_Not_Found** · 04/10/21 20:02:54

スマソ、>>308は>>306宛てね。

**Name_Not_Found** · 04/10/21 20:06:55

AAは文書じゃなくて画像だって言ってんだろｚ；ｗｌｋｊｆｄ；おいうｔ
strictではAAなんて考慮されていない。strictなAA表現なんて現段階では存在しない。
だから非strictで好きなように書け。どう書いたってvalidにはならん。以上。

**308** · 04/10/21 20:09:56

>>310
いやだから、単なる暗号文字列だと思っておけばいいじゃんって話なんだが。
考慮されてないんだからわざわざ画像だと思う必要もない。

**Name_Not_Found** · 04/10/21 20:17:40

AAってのは言ってみれば「あるやり方でデコードすると画像になる文字列」。
HTML側でデコード方法が考慮されてなくても、単純にエンコード文字列として
記述するのはstrictとして別に変じゃない。

**Name_Not_Found** · 04/10/21 20:26:03

考えようによっては
<div class="AA" xml:space="preserve"><![CDATA[ジェンキン寿司]]></div>
みたいな感じでも良いかもね。
やっぱりフォントの問題は解決できないけど。

**302** · 04/10/21 20:35:12

>>306
文字という本来別の用途のあるものをあえて使い図形を表現するという
AAのなりたちから言えば、あるタグが本来想定した意味合いを意図的に
無視して技巧を凝らすことこそがAA的と言える。
Strictという制約を設けたうえでそれを行うのもひとつのありかた。

**Name_Not_Found** · 04/10/21 20:36:12

まあ正しく伝えたいんなら画像ファイルを用意するべきだわな。
どうしても文字で書きたいって状況があまり想像できんが、こんな感じか？

<p><img src="smiley.png" alt="smiley">はこう書きます。</p>
<pre>:-)</pre>

preの中が顔の形として伝わる期待はできないが、どういう文字を
並べて書くと言いたいのかは伝わるだろ。

**Name_Not_Found** · 04/10/21 20:37:48

なんだかもりあがってるね。

>>278
「あぁ、規格通りのコードを書いている私は今、確実に美しいぃ！」

ﾜﾛﾀ

**Name_Not_Found** · 04/10/21 21:16:07

CSSスレから誘導されてきました。

http://www.aki7.com/cgi/up/c-board.cgi
ここにある「通販のよくあるレイアウト例」っていうデザイン案をstrictHTML+CSSで仕上げるには
みなさんはどう実現しますか？