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/10 13:16:40

長方形になっているという保障がないじゃん
jaggedになってるだけかもしれんし

**Name_Not_Found** · 04/10/10 13:25:31

>>162
現在の仕様書でも、

<table>
<tr><td>あ</td><td>い</td></tr>
<tr><td>う</td></tr>
</table>

は許されてるよ。足りない部分は空セルが補われる。ギザギザでも問題なし。

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

>>161
liだと縦の関係が示せないとか

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

3次元くらいならまだしも
4次元になると並の人間には構造が理解できない罠
どっかの数学者は4次元空間を頭の中で構築できているらしいが

**Name_Not_Found** · 04/10/10 15:33:26

っていうかどうでもいいことにいつまでも執着しやがってオンドレリャー！

オッフェ(=ﾟωﾟ)ﾉ♪

**Name_Not_Found** · 04/10/10 16:24:40

>>164
>>141
classはCSS専用のグループ属性というわけではない。
(本当にグループ化されているという保証もないが)

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

>>167
>(本当にグループ化されているという保証もないが)

どういう意味だよ？
CSSで理解できるんだから当然グループ化に成功してると言えるだろ？
もちろん論理的な意味などは伝えられないけど、単純にグループするのはできてるよ。

**167** · 04/10/10 17:51:48

>もちろん論理的な意味などは伝えられないけど、
正にその意味で「保証がない」と述べた。

Strict-HTMLにおけるグループ化は必ず論理的な意味での
グループ化でなくては意味がないが、CSSのターゲットとしての
classによるグループ化はしばしば論理的ではない場合がある。
例えvalidなStrict-HTMLであっても。

**156** · 04/10/10 19:32:40

>>151
俺が言いたかったのは>>159の通りで、
純粋な内包関係で表現できないってことね。

純粋な内包関係ならXpathで言うところの
「述部」を使用しなくても表現できる。

Tableで言うと同一行は「table/tr[foo]/td」で選択可能。
それに対して、列は
「table/tr/td[position() = foo]」
みたいに、セルを表す要素に直接述部を書かないといけなくなる。

個人的には内包関係から外れた関係はどうにも気持ち悪いね。

**Name_Not_Found** · 04/10/11 00:24:53

>>169
>Strict-HTMLにおけるグループ化は必ず論理的な意味での
>グループ化でなくては意味がないが、

一体仕様書のどこをどう読んだらそんな解釈できるの？
classは「何の」グループかを伝えることはできないけど、
それが「ひとつの」グループであることを伝えることはできる。
っていうか正にそういうもののためのもの。構造を知らせてれば
意味などは伝える必要はない。

>CSSのターゲットとしての
>classによるグループ化はしばしば論理的ではない場合がある。

classはそれらがグループであることを伝えるためのもの。別にグループ自体の
論理性などは微塵も関係ない。例えば「赤」のグループに「青」が混じっていても
問題はない。作者がそれを同一グループだと主張しているのに、何故、否定
する必要がある。

**Name_Not_Found** · 04/10/11 00:30:15

こんど
オッフェ(=ﾟωﾟ)ﾉ♪
これをサイトで扱うことになった。

<h1>オッフェ(=ﾟωﾟ)ﾉ♪とは</h1>
<p>つまりオッフェ(=ﾟωﾟ)ﾉ♪とはあからさまに人を馬鹿にした顔文字である。
きみらはそんな大人にならないように気をつけてくれ。</p>

どうだい？

**169** · 04/10/11 01:07:34

>>171
正にその通り。だから >>167 の様に書いた。

俺が述べたのはStrict-HTMLでのclassは
「論理的な意味でのグループ化でなくては意味がない」
であって、
「論理的な意味を『伝える』グループ化」
ではない。

**Name_Not_Found** · 04/10/11 01:08:27

>>172
DFN要素が足りない。

**Name_Not_Found** · 04/10/11 01:16:25

>>173
う～ん・・・
だから
＞「論理的な意味でのグループ化でなくては意味がない」
これが間違いなのよね。

どこにも「論理的なグルーピングでなくてはいけない」なんてことは書いてないのよね。
そもそもグループ付けに非論理的とか論理的とかないから。

**Name_Not_Found** · 04/10/11 01:59:48

>>175
「○○～でなければ『意味がない』」を「○○～でなければ『いけない』」に
読み替えて、その上で「そんなことん仕様に書いてない」って云うなら
そりゃそうだろうなぁ。

なんでStrict-HTMLでは「意味がない」のかと云えば「見栄えの為のclassを
用いるならそれは見栄えの為のマークアップであって、Strict-HTMLが
わざわざ見栄えの為の要素を無くした『意味がない』状態になるから」であり、

仕様のどこを読んでも「『論理的なグルーピングでなくてはいけない』なんてことは書いてない」
と言われれば全くその通りだし、そんな主張は誰もしてない。

**Name_Not_Found** · 04/10/11 02:37:16

>>176
>『意味がない』」を「○○～でなければ『いけない』」に
>読み替えて

ほんとに読み替えてたよ＾＾；
しかし「意味がない」は言いすぎだよ。100点でなきゃ意味がないっていう学生くらい
極端だね。

それに「見栄えの為のclass」って例えば何？
俺は「見栄えの為のclass」なんて思いつかないな。だって視覚からだって論理性を
伝えられるから。

class=first
これは問題ない。
class=red
これは名前がイマイチなだけでグループとしては問題ない
...っていうか全然思いつかないわ；

**173=176** · 04/10/11 03:44:45

>>177
>しかし「意味がない」は言いすぎだよ。100点でなきゃ意味がないっていう
>学生くらい極端だね。
だから「Strict-HTML "では"『意味がない』」ってわざわざ条件つけとるやん。
しかもここはStrict-HTMLやで? しかも実運用上、理屈通りに行かない事は
>>169 でのべ、更に >>173 では >>171 を全肯定しとるやん。

>それに「見栄えの為のclass」って例えば何？
>class=first
>これは問題ない。
classがどんな目的で記述されたかと、どんな文字列か、は全く別でしょ?
そんな事指摘されるまでもなく、解ってるでしょ?

たとえredだろうが、blueだろうが、ちゃんとした文書構造を象徴していれば
Strict的に意味のあるグルーピングだし、firstだろうが、なんだろうが、
例えば font 要素の代用として見栄えの為に用いられていたら、
それは見栄えの為のclass。

例えば<font size="6">を<span class="first">に置換しても、
validなStrict-HTMLにはなれるかも知らんけど、Strict-HTMLとして
意味のあるclassとはいえない。そう言う事。

**Name_Not_Found** · 04/10/11 03:54:16

>それに「見栄えの為のclass」って例えば何？
>俺は「見栄えの為のclass」なんて思いつかないな。だって視覚からだって論理性を
>伝えられるから。

流れを読まずにレスするが、例えばメニューをfloatさせるときに
class="right"とかやったら論理性の伝わらないクソなclassだってわかるよね？

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

相手の勘違い振りが判明する度に口調がぞんざいになる >>178 にﾜﾗﾀ。

**Name_Not_Found** · 04/10/11 05:46:43

>>178
>ちゃんとした文書構造を象徴していれば
だからその文章構造を象徴してないclassって何？ってことなんだけど。

＞例えば<font size="6">を<span class="first">に置換しても、～～
いや意味のあるclassだと思うよ。というか意味のあるグループ付けだと思うよ。
いや、これは例が悪いこれって強調っぽいからね。

なんていうかね、スタイルの時点で追加するclassでもほとんどは文書構造をあらわしているものが
ほとんどだよ。見栄えがそこだけ変わるなら、当然構造も違うんだといいたいんだろうから。

もう少しだめクラス例のいいのをきぼん

>>179
場合によるね。名前はどうせ関係ないから。
それにid=menuでやるものだからなぁ・・・
そしてもしもid=menuのかわりに名前をデタラメでclass=rightとしてるなら
グループとしては間違いではない。まあclass=menu-aとかのデタラメ版かな。
UAにとっては差のないことね。

やはりもう少しいい例があるといいな。
意外にないんだよ。ダメなクラスの振り方って。
ダメなクラスの振り方＝ダメなグループ付け＝だめな関連付け
だからね。hogeとhogeを関連付けちゃいけないってどんなのよ？って。

赤くしたいのにclass=redで、とにかく文字を赤くしたいhn,span等全部に
class=redでもCSSを頭からなくしたときに、それらが関連付けられてては
いけない理由が浮かばないのね。

**Name_Not_Found** · 04/10/11 06:00:47

>>181
>それらが関連付けられてては
>いけない理由が浮かばないのね。
関連付けられてていいのか悪いのかでなく、そのclassは文書構造を象徴してるものなのかだろ。
まあ作者が象徴してると言えばそれまでだがなｗ

どちらにしてもclassなんてどんな付けかたしててもいいと思う漏れは勝ち組だな。

**Name_Not_Found** · 04/10/11 06:57:17

classなんて付けないのが本当の勝ち組

**Name_Not_Found** · 04/10/11 07:15:07

>>181
>それにid=menuでやるものだからなぁ・・・
>そしてもしもid=menuのかわりに名前をデタラメでclass=rightとしてるなら
>グループとしては間違いではない。まあclass=menu-aとかのデタラメ版かな。

もしもid=menuのかわりに名前をデタラメ～なら間違いない、ってんなら（中身には突っ込まん）
id=menuのかわりでなく名前が見栄え意識でclass=rightなら間違い、ってことだろ？
自分で仮定しといてその反例（の導き方）がわからんとはどういう構造しとるんだお前の頭は。

**Name_Not_Found** · 04/10/11 07:23:19

クラス名をどうしようが、機械的には関係ない、っていうのが最終的な答えだろ。
その意味では目的に見合った構造化化がされていれば、
「red」でも「inoki」でも問題ない。

良く推奨される、「理論的な名前付け」は
「文脈を推理できる人間」にしか通用しない、
よって、無意味、と考えるのが、
個人的には正しいStrictだと思が、
要素でのマークアップに理論性を求める面からすると
「どうせならクラス名にも理論的な名前付けようぜ」
と思うのなら、それはそれで有り。

ただし、DTD上に定義されていないので、
あくまでも自己満足だよね。

**Name_Not_Found** · 04/10/11 10:25:13

>>184
>もしもid=menuのかわりに名前をデタラメ～なら間違いない、ってんなら（中身には突っ込まん）
>id=menuのかわりでなく名前が見栄え意識でclass=rightなら間違い、ってことだろ？
もしそうであればclass=rightでも間違いではないってこと。だから真逆。
名前などどうでもいいのよ。構造には無関係だから。

名前から構造を考えず、実際のグルーピングとして正否を。

**Name_Not_Found** · 04/10/11 11:37:03

>>例えば<font size="6">を<span class="first">に置換しても、～～
>いや意味のあるclassだと思うよ。というか意味のあるグループ付けだと思うよ。
>いや、これは例が悪いこれって強調っぽいからね。

これって、そのまま読み替えると

font size="6"は「ある意味論理要素だと思うよ」「いや、これは例が悪いこれって強調っぽいからね。」

となる訳だが。

結局釣りだったか。

**178** · 04/10/11 11:41:50

釣りっつーか単なるアホだろ。
相手して悪かった。ごめんな。

**Name_Not_Found** · 04/10/11 11:44:17

>>187
>となる訳だが。
ならないけどね。
font要素とグルーピングが同じなわけないだろ。

**Name_Not_Found** · 04/10/11 11:49:43

アフォ同士の喧嘩か？ｗｗｗ
ほんとストリクトにこだわるやつってアフォだよな（ﾌﾟｯ
軽く池沼レベルだな（ﾌﾟｹﾞﾗｯﾁｮ

**Name_Not_Found** · 04/10/11 11:57:17

どう騒ごうが結局はアレフ0ですよ

**Name_Not_Found** · 04/10/11 19:49:57

なんか最近は論破できないと悟ったら、相手を貶して自己防衛する子供っぽい人が
多いね。

自論を理解してもらえない→相手が馬鹿だからだ

っていう発想はやめようよ。

**Name_Not_Found** · 04/10/11 20:30:20

>>192
本当に聞くべき相手は聞く耳持たないからそういう発言は意味がない

**Name_Not_Found** · 04/10/11 20:45:12

論破できないにも２種類あって、自分が間違ってた場合と、
相手が話にならない場合があって、

後者の場合、「相手が馬鹿だからだ」の流れはかなり昔から２chにあったし、
前者の場合、さらに昔から２chにあった。

つまり、その傾向は最近でもなんでもない。

ただ、そういう傾向を前面に出すバカが最近このスレに増えたのは確か←ほらね

**Name_Not_Found** · 04/10/12 02:01:14

**Name_Not_Found** · 04/10/12 10:06:42

>>194
うん。他のスレでは普通のことでもここではやめてほしいね。

**Name_Not_Found** · 04/10/12 12:01:51

それは無理！
だって>>189とか池沼レベルだから崇高な俺達の言うことを理解できるわけがない。

**Name_Not_Found** · 04/10/12 13:12:23

そうやって自惚れるから荒れるわけだが。

**Name_Not_Found** · 04/10/12 14:37:03

まぁ、本来有意義な話題があって、スレが流れていれば、
荒らしや天然が来てもスルーして話が流れるし、
そうなれば住民のレベルも上がるので、さらに荒らしは寄りつきにくくなり、
天然も「あ、俺違うかも」と気付く物ですよ。

要するに、慢性的に話題がないのが問題。いっそ XHTML2.0スレとでも合併して
次世代の XHTML に付いてでも話していた方が、いざ HTML 4.01 の話題になった
時でも高いレベルが維持出来るんではないかと思うくらいに。

**Name_Not_Found** · 04/10/12 15:50:26

> 要するに、慢性的に話題がない
つまり、このスレはもう役目を終えているわけですよ。

> いっそ XHTML2.0スレとでも合併して
話題がないからスレの主旨を拡大して、とかいう
いつか聞いた提案の再来ですか？

**Name_Not_Found** · 04/10/12 16:16:59

>このスレはもう役目を終えているわけですよ。
本当にそう思っているなら、ここで雑談するのは止めて、
dat落ちするまで待てば宜しい。

書き込みが有る以上、生きているスレと言わざる得ない。
しかし、慢性的に話題がなく、ループを繰り返すゾンビスレであるのも確か。

>話題がないからスレの主旨を拡大して
合併するのだから、合併した時点で別スレに成ってる訳で、主旨の拡大ではない。

>いつか聞いた提案の再来ですか？
いつか聞いた提案の再来だとして何か？

**Name_Not_Found** · 04/10/12 16:43:20

>>210
datオチしたら誰かがまた立てるんじゃないか。

＞要するに、慢性的に話題がないのが問題。
それと荒らしと何の関係が？そもそもこのスレは住人自体が荒らしになってるから困るんだよ。
住人＝荒らしを注意しても責任転嫁ばかりで反省をしてくれない。

とりあえず話題がないならこなければいい。ここにいたい人間はまだいる。（俺も含めて、
毎日1回はのぞく人間が多少はいるみたい）話題がないからといってここを荒らすのだけは
やめてくれよ元住人さんたち。

strictを学ぶ前に「大人」を学んでほしいm(_ _)m

**Name_Not_Found** · 04/10/12 17:22:33

>それと荒らしと何の関係が？
see >>199

>住人＝荒らしを注意しても責任転嫁ばかりで反省をしてくれない。
you too.

話題がないなら、書かないのが一番ですよ。
荒らしは罵倒だろうが、論議のフリだろうが、反応して貰うのが一番嬉しいんだから。

**Name_Not_Found** · 04/10/12 17:38:15

indeed

**Name_Not_Found** · 04/10/12 17:40:16

>>203
それは違うでしょ。
どうして荒らしを擁護するような発言ばかりするのよ？
まるで「今の状況なら荒らされても文句は言えない」みたいな風潮になってるけど、
それは間違ってるよ。そういう風潮だから「荒らしてもいいか」みたいに思って
実際に暴言を吐く元良住人が出てくるんだよ。

とにかくこのスレを荒らすのはやめてください。

**Name_Not_Found** · 04/10/12 17:56:28

>>205
>話題がないなら、書かないのが一番ですよ。
>荒らしは罵倒だろうが、論議のフリだろうが、反応して貰うのが一番嬉しいんだから。

ちなみに、最近の切っ掛けは ID がでなくなったことだと思う。

**Name_Not_Found** · 04/10/12 18:08:09

> とにかくこのスレを荒らすのはやめてください。

典型的な「荒らされるパターン」振りに脱帽。

**Name_Not_Found** · 04/10/12 18:51:47

>>206
そうだよな。強制IDにしてほしいな。
>>207
幼稚なレスはやめとけ

**Name_Not_Found** · 04/10/12 18:54:22

>>206
最近のに関しては、出なくても分かるような気がしなくもない。

**Name_Not_Found** · 04/10/12 19:44:31

>>209
わかってもしょうがない
やっぱIDは出ないとダメだよ

**Name_Not_Found** · 04/10/14 08:08:21

技術系の板なんだからIDあった方が便利だよな。

**Name_Not_Found** · 04/10/14 08:15:31

えっ？
ここって雑談系２じゃなかったの？

**Name_Not_Found** · 04/10/14 12:02:08

>■扱う話題■
>* HTML、CSS、FLASHなどのサイト制作の技術
>* JavaScript、VBScriptなどのクライアントサイドプログラム
>* Webサイトの運営および管理についての情報交換・雑談

つーわけで、両方とも板範疇ではあるが、このスレ自体はどう考えても
>* HTML、CSS、FLASHなどのサイト制作の技術
かと思われ。

もし、雑談スレのつもりなら、スレタイと >1 を変えた方が良い。

**Name_Not_Found** · 04/10/14 14:53:39

意見が聞きたいんだけど…

dfnって定義部を明示するわけじゃん
だったら定義内容はどうやって明示するの?

ｾｯｸｽの2ch語をｾｯｸﾙといいます

例文がｼﾓで悪いが、dfnはｾｯｸﾙ。では定義内容の「ｾｯｸｽの2ch語」はどう明示する?
ｾｯｸﾙって語彙を定義しておくしか無いかな?

ってな事を考えてて、誰か2ch語の語彙を定義して公開してくれないかなーと思った
日記＆ﾒﾀな話でｽﾏﾝ
よかったら意見聞かせてほしい

**Name_Not_Found** · 04/10/14 15:39:08

定義内容の範囲がきっちり明示できないような場合も多いんじゃないかな。

**Name_Not_Found** · 04/10/14 15:39:18

<dl>
<dt>ｾｯｸﾙ</dt>
<dd>ｾｯｸｽの2ch語</dd>
</dl>

**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で言語マーカーを生成するとき、その内容に国旗のアイコンを使用すべからず。