Strict-HTML スレッド 41

StrictなHTMLについて語るスレッド。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 スレッド 40
http://pc11.2ch.net/test/read.cgi/hp/1172418901/

暫定まとめサイトはhttp://wiki.fdiary.net/StrictHTML/

初心者の質問はこちらへ
Webサイト制作初心者用質問スレ Part 187
http://pc11.2ch.net/test/read.cgi/hp/1187281010/

実装の話は10中8, 9スレ違い。

関連スレは>>2

/* CSS・スタイルシート質問スレッド【67th】 */
http://pc11.2ch.net/test/read.cgi/hp/1185234189/

XML→XHTML
http://pc11.2ch.net/test/read.cgi/hp/1039933755/

@media:all { 真のアクセシビリティ }
http://pc11.2ch.net/test/read.cgi/hp/1034270272/

ユーザビリティ専用スレ　その３
http://pc11.2ch.net/test/read.cgi/hp/1136275352/

【みらくる】XHTML 2.0 (その2)【ドリーム】
http://pc11.2ch.net/test/read.cgi/hp/1098711758/

XML使いのスレ 2.0
http://pc11.2ch.net/test/read.cgi/hp/1057198990/

XSL/XSLT
http://pc11.2ch.net/test/read.cgi/php/999654569/

>>1 乙

Strict-HTMLスレッド まとめwiki

http://wiki.fdiary.net/StrictHTML/?FrontPage

>>4
strictスレのwikiが糞マークアップって笑い話にもならん

しょうがないじゃん
wikiエンジンがそこまでいいものじゃないんだから

割としっかりしたマークアップをするけど低機能で書式が独特なウィキなら提供できます｡

あ､ やっぱり提供できない｡
閉じられた場で使うことを想定して開発したものだから､ いたずらに対して脆弱過ぎる｡

アフィリエイトが付いてます

ID名に小文字は使うべきじゃない？
小文字も大文字として取り扱われるから

初心者スレ行け

>>10
ISO-HTMLなら大文字じゃないとだめ

ストリクタならHTMLは全部大文字
これ

どれ？

まあ、ID問題はISO-HTMLの問題じゃなくて、SGMLの問題だから、
HTML4.01でもそうだな。

<h3 id="naviMenu">

前スレより
table要素内のcaption要素 = table要素のtitle属性

んなわけない

IMGにもTABLEと同じようにCAPTIONを表現するにはって流れのやつか
IMGにTITLE属性をつけるだけでおｋ
みたいなこと言ってる人がいたな

title属性は「助言的な情報」を表すと仕様書にある通り、ただの付加情報に
過ぎない。だから、その部分のタイトルを表すわけではない。

title属性っていう名前が誤解を与えるんだよな。
実際はcomment属性ぐらいの意味だと思うが。

XHTML2とHTML5どっち支持？
俺はXHTML2なんだが。5のheader要素とか
それidかroleでいいじゃんとか思う

どっち支持とか言われても普通に使えるようになるの後何年後？w

思想や設計的にはXHTML2支持だが
普及はHTML5のほうが早そうだ…

> title属性は「助言的な情報」を表すと仕様書にある通り、ただの付加情報に過ぎない。
どの程度の意味合いなの？本当にどうでもよくて書いても書かなくてもいいくらい？
abbr acronym link以外の要素において

「どの程度」なんてのは仕様書に書かれてないので、各自の判断だろう。
ただ、重要な情報なら属性ではなく本文に書くべきだと思う。

なんかもうtitle属性って一般属性じゃなくてもよくね？

<link rel="stylesheet" type="text/css" href="xxx.css" title="xxx" ...
ここも用途からするとtitleじゃなくてclassな気はする

んなわけねーよ

んなわけねーことねーよ

糞仕様も仕様

それは仕様がない

今サイトを作っているのですが、別に<br>を使っているわけでもないのにコンテツが下に下がってしまうんです。
何故かわかる方いませんか？

>>32
すれ違いです。

沢山その手のスレがあるのに
なぜStrict〜などという一般人（謎）には
わけわからんスレを選ぶのだ？

>>34
HTML 4.01 Strict とか XHTML 1.0 Strict とかと勘違いしてるんじゃね？

35の言わんとしていることがわかるようでわからない

>>36
「HTML 4.01 Strict」や「XHTML 1.0 Strict」に valid なHTMLを書いて、
なおかつ、表示なども思い通りにする技を話し合う
ってのと勘違いしてるんじゃね？

今サイトを作っているのですが、
パンくずリストのマークアップについて云々…とかだったら
このスレ的にもありなんだが。

俺はパンくずリストはOLで書いてる。

・リスト派(ul, ol, dl)
・パラグラフ派（p。ただしaの羅列ではなく、言葉を補った自然な文で）
に分かれるのかなな。前者のほうが多そうだが。

おれはp。視覚障碍者の方々のために適切な語をspan.accessibility
とかで補って、そいつらだけtext-indent:-9999px;してる。

display:none;じゃ読み上げてくれないんだっけ

おまいらはアフィリエイトのリンクとかも
ちゃんとxhtmlなら&を&って書いてるんか？

>>42
俺はアフィリエイトリンクの&も実体参照にわざわざ書き換えてるよ。
整形式にしないとXSLTが通らないしさ。

>>40
リスト派にも入れ子派と並列派に分かれそうな。

ol→並列
ul→入れ子 / <li>トップ > 各種資料と情報源</li>
dl→入れ子

パンくずナビ、うちもリストにしたりPにしたりうろうろしてたんだが、
辞書にさえ

breadcrumb
【名-1】 パンの中の部分｛ぶぶん｝
【名-2】 ブレッドクラム（機能｛きのう｝）
　　　◆ウェブサイト内で訪れたページをリストアップしたもの。
　　　大抵ページの上部に表示される。例えば「ホーム⇒商品⇒デジタルカメラ」のように、
　　　どういうルートをたどって今のページに至ったかを示す。

ってあるくらい一般的な機能として定着してるわけなんだから、もう

<dl id="breadcrumb">
　　<dt>Breadcrumb</dt>
　　<dd><a>ホーム</a> <abbr title>⇒</abbr> <a>商品</a> 以下略</dd>
</dl>

とかって書くのも、それはそれでありなんじゃないかという気がしてきた。
考えすぎて複雑にするのもなんか冗長だなあと。
そのうち専用の要素とかできたりしてｗ

辞書にのっててもパンくずリストという名前、
ましてやブレッドクラムなどという語は
一般には膾炙してないだろうから
「現在地」とかのほうがいいと思う

topic pathじゃないかい一般的には

普通の人は名称なんて意識せず
「あ、上にのぼる便利なやつだ」くらいの認識じゃないの？
専門用語は使わないほうがいいのでは…

topic path は階層的に現在の位置を表したもの、
breadcrumb はその通り来た道を示したもの、って感じだなー

「パンくずリスト」 って言ってても breadcrumb じゃなく topic path なことが多いって気はする。

>>49
語源はそんな感じだな。
ただ英語圏でググってもbreadcrumbが定着してるみたいだ

よし、両方とも設置しよう。

メニューの書き方アンケート in Strict-HTML スレッド

A、Bそれぞれにお答えください（メニューを置いていない人はスルーしてください）


A-1 ul,liを使う

A-2 ol,liを使う

A-3 dl,dt,ddを使う

A-4 pを使う

A-5 その他（具体的にお書きください）


B-1 ホームと他のコンテンツは同列
・ホーム
・コンテンツ１
・コンテンツ２

B-2 ホームに他のコンテンツがぶらさがる形
・ホーム
　・コンテンツ１
　・コンテンツ２

B-3 ホームを載せない
・コンテンツ１
・コンテンツ２

B-4 その他
（具体的にお書きください）

まずメニューを定義してくれ
グローバルナビゲーションだけでいいのか？

いいとも。

A-4＆B-1

a4b2

A-1 B-1

A-1, B-1

>>52
A-1, B-1

その他でもいいんだぞ

link要素

>>52
メインでやってるサイトではtopic pathのみだが、
サブでやってるサイトでは使っているので答えてみます。

A-5 その他（具体的にお書きください）
階層深くてもごちゃごちゃしすぎるから、
一段階のみのカテゴリ名リストと対するリンクリストの二段階のみで構成。
<dl><dt>カテゴリ</dt>
<dd><ul>
<li>リンクリスト1</li>
<li>リンクリスト2</li>
</ul></dd></dl>

なお、<h1>に対してナビリンクは関係がないので<dl>にしているが、
<h1>に常にサイト名を出すなら、<h2>ナビリンク</h2><h3>カテゴリ名</h3>として
メニューは<ul>のみにするかなと思う。

B-1 ホームと他のコンテンツは同列
homeは、profileやBBSやaboutなどをまとめた
最上段に存在するカテゴリの一番上に置いている。

>>52
A-1、B-1

A-1 B-1

1年前は A-3 だったなあ。

>>52
A-2
B-1

B1の人気に嫉妬

メニューはul,li派が多いのか

携帯サイトだとol派が多数？

携帯サイトのボタン押しでリンク選択は
olの番号と関係あったっけ？

ない

B-2が少ないのは匿名ブロックを気にして？
B-3に至っては誰もいない

トップページは A-1,B-3
その他のページはパン屑のみ

実際のところメニューのマークアップにこだわっている人は
あんまりいないんじゃないかと推測。

どういう根拠で？

「仕様やガイドラインで厳密に定められてないならなんだっていい」
と73は思ってるんじゃね？

>>75
どういう考え方をしたら
>「仕様やガイドラインで厳密に定められてないならなんだっていい」
>と73は思ってる
と思えるの？

html5ではメニュー用の要素が復活するんだっけ
匿名ブロックボックスの問題が解消されて

<nl>マダー？

>>76
>>73みたいな推測をするのは、夏だからじゃないかという考え。

全角スペースはWebブラウザで本来無視されます。

Strict-HTMLの皆様方は、どんなツールを使って文章を作成しているんでしょうか？

執筆自体は、Wordでアウトライン機能と文章校正機能の恩恵を受けつつやるのが便利だと思います。

でも次の段階で、Word文書から、p、h1、h2、h3、strong、code、table、imgといった基本的な
タグだけが使用されていて属性は全く記載されていないhtmlへ変換しなければなりません。

考えつくのは、

1.Wordが出力するhtmlから属性値、不要なspan、divやCSSを削除するアプリケーションがある。
2.一旦テキストファイルに落としてから、オーサリングツールでタグを付け、そのあと画像や表の配置を行う。
3.Wordを使わず最初からテキストエディタ又はオーサリングツールを用いて文書を作成する。

やっぱり2でしょうか？

Emacs + PSGMLで書いてる。DTDを用意すればどんな文書型にも対応できるので
個人的には最強だと思う。2は一番謎なのだが。

俺もEmacsだな。慣性。

俺もEmacs。WindowsもWordも持ってない。

3.っていうのかな
そん時々で適当なエディタを使ってる（構造化エディタ,Crescent_Eve,xyzzyの順でいずれか）

マークアップは基本的にFEPに単語登録してるのを利用。

２は私にも謎

文書の中身だけテキストファイル形式で保存
何かオーサリングツールでマークアップする
CSSで整形

と予想
真ん中の工程のみ実践するのは難しそうだが。

>>81
私は3かなあ。
HTML制作は全部テキストエディタで、ソフトは秀丸。
私はモノ書きでもプログラマーでもないし、充分です。
ついでにWordもExcelも持ってないし。

ただ、今後は自家製XMLで書いてXSLTで変換する感じで、
ヘッダーとかナビとかの冗長部分を簡素化して書けるようにしたい。

>>81
http://pc11.2ch.net/test/read.cgi/hp/1187281010/351
同じ人？

ご返事ありがとうございました。
テキストエディタでフルスクラッチという方が多いんですね。

2は>>86の言われるとおりのことです。

> 真ん中の工程のみ実践するのは難しそうだが。

難しいですかね？

最初は、dreamweaverでソースとレンダリング結果を同時に表示した状態でテキストを直打ちして、
適宜マークアップや図表の挿入をしつつ作成していました。でも、文章が長くなるにつれて、テキストだけは
Wordで書いた方が良いような気がしてきたのでした(>>81の利点があるので)。

ただ、HTML出力をWordで行うと、p、h1などは意図したとおりになるのですが、class属性、要らないdivや
spanが残ってしまいます。また、dreamweaverには「Word HTMLのクリーンアップ」という機能があったのですが、
対象となるWordのバージョンが古いようで、やはり属性や要らないタグが残ってしまいました。

結局、一旦テキストファイルにして、マークアップの追加、表の作成や図の挿入は改めて行うのが一番安心な
方法だと結論したのですが、他の人はどんな具合にやっているのかな？と興味を抱き質問してみました。

>>88
違う人です。そっちのやりとりは今読みました。
私の方は、Strict HTMLに注意を払っている人のやり方や考え方を聞きたかったのです。

wordとか立ち上げるのも重いからなあ…
常駐させとくのもメモリ食いまくるし。
もっと軽くてHTML出力あるアウトラインエディタ使えば？

自分は秀丸でフルスクラッチ

あ、フルスクラッチとはいっても本文だけで
テンプレ管理やアーカイブ化にブログツール（Movable Type）使ってる。

次はブログツールのアンケートになりそうな予感
俺もMT

otbedit

秀丸良いよな。
たまにCSSのプロパティど忘れてググる羽目になるのは俺だけジャナイハズ。

>HTML5にi要素ある？pの中の

i要素じゃないや
l要素か

l要素あればparagraph問題解決するかなぁ

俺は
margin/padding、border、width/height、
background/color、display、font系、text系
くらいしか覚えてない

Texとか使ってるやつもいそうだな

ふるすくらっちってなんですか？

ゼロから書いてるってことだろ

前に書いた似たページのファイルをコピーしてから編集ってのがデフォなので、
完全にフルスクラッチなんてまずしないな。特にhead部分とか。

>>98
「ゼロから書いてる」と言うより、
フルスクラッチって言ったほうがカッコイイでしょ？

右クリック → 新規作成 のテンプレファイル作ってないの？

from scratch（フロムスクラッチ）から転じた和製英語だな

自分も一つテンプレート作ってコピーしてる。毎回文書型宣言から全部書い
ている人なんているのかな。

ttp://www.atmarkit.co.jp/fwin2k/win2ktips/282filenew/filenew.html
マジ便利。

Windowsは持ってない。だいたい右クリックなんて面倒な操作をするより、
コマンドラインから cp と打ち込む方が楽。

同じ数字のhn（たとえばh2）が複数存在する場合
出現順にやっぱり意味があるんですか？それとも順不同？
ol的なのかul的なのか、みたいな

hn要素は出現順に意味があるか無いかを意味づけされない。
「意味がある」とも「意味がない」とも言及しない、ということ。

>>106
一生GUIを使うな

>>107
hn要素は見出しとしてマーク付けするんだから、質問がおかしい。
テキストは出現順に意味があるのか、ならわかるがそれはスレちがい。

>>109
僻みｶｺﾜﾙ

>>108
>>110
どうもありがとうございます

>>111
ｽｺﾞｲﾈｰ ﾖｶﾀﾈｰ

cpとかmvとかってファイル名が不規則なときに面倒じゃないって思うんだが、
完璧スレ違いだな。

なんで俺が書いた事に関して、別の2人がなじりあってんだか。

>>114
固定部分はシェル変数登録、変動部分はファイル名補完を使えば、
そんなに面倒なことにはならないと思うんだが。

慣れるとcuiは便利らしいし否定はしないけど>>111はかっこ悪すぎるｗ
どうせ釣ったつもりなんだろうけど。

カッコで生きてる無能同士仲良く汁

本人登場

右クリックが面倒なのは禿同、というかマウス大嫌いだが、
GUIの視認性や同時進行(マルチタスク)の把握しやすさからはもう戻れない。

HTMLファイルを新規作成すること自体そんなにないし、
その時は別のHTMLを適当に選んでコピった方が楽だな。

頻繁に新規作成で増えるコンテンツとかはスクリプトで自動生成だな。
スレチスマソ。

章ごとにページ（ファイル）を分けている一連の文章があり
各章ごとに（各ページごとに）脚注を載せるには
このスレ的にはどうマークアップするべきですか

<p>1/10</p>とか
<p>全10ページ中の1ページ目です。</p>で必要十分。

それってようするに後注じゃね？

他の部分のマークアップとの整合性とかとれてて、
へんなことしてなきゃどうでもいいんじゃね。

titleとページ末尾に>>121みたいなのと
<link rel="(next|prev)" />と
あとページ移動のナビがしっかりしてればいんじゃね

>>121
それって脚注？ノンブルじゃなくて

脚注って言うと書籍などで本文中に「なんたらである[*1]。」ってあって、ペー
ジの下に[*1]の説明がついているようなやつを想像したんだが。

>>124
> 脚注って言うと書籍などで本文中に「なんたらである[*1]。」ってあって、ペー
> ジの下に[*1]の説明がついているようなやつを想像したんだが。
それです
というかそれ以外にも脚注ってあったんですね
説明不足ですみません

ページ下部の注が脚注
章や節の末尾につける注が後注
ページ下部のページ数表記がノンブル

脚注もだし>>121もだけどメインの文章との区別が付かなくなるからページ下部に配置できないんじゃないか

んむ
DIVコンテナ否定論に則ると
見出し要素でしか区切れないので
本文と区切りたいのなら脚注にも見出しを付けるしかない
しかし全体を通してみると本文の合間合間に
脚注の見出しが入ることになり階層構造を崩すことになる
なので
脚注を表現することは
不可能

つ<hr />

見出しのみでしか階層構造が造られないという
実在しない仕様で不可能だとか9行掛けて語らんでも

脚注の見出しのレベルを1つ下げとけば別に階層崩れないんでない？

Wikipediaだって、脚注には見出しをつけるのが習慣になってるし、
あんな感じでいいんじゃないか？

wikipediaはページごとに完結してるじゃん

120を読んでないのはおまえだけ

>>130
> 実在しない仕様で不可能だとか9行掛けて語らんでも

>>128
> DIVコンテナ否定論に則ると
という話でしょ
divやhrで本文から意味を切り離せるというのも実在しない仕様だし

hnでしか区切れない派とdivやhrでも区切れる派それぞれが
仕様の行間を妄想して戦っている

結局これ答えが出てないんだよね
出てないというか出ないというか

脚注って言うのかわからんが、自分は
<p>なんとかかんとか^{<a href="#note1">[1]</a>}。</p>
...
<dl>
<dt>注</dt>
<dd>
<ol>
<li id="note1">ほげほげ</li>
</ol>
</dd>
</dl>
こんな風に注をつけている。

olじゃないほうがいいんじゃない？
[1]とli#note1が対応しているだけだし。

それli要るのか？
<dt>注[1]</dt>
<dd>ほげほげ</dd>
だけでいい気がするんだけど。

>>135
区切るものなんて無い派も無視しないで欲しいな。

>>135
> 本文から意味を切り離せる
「本文」なんて意味づけはHTMLに無くね？

・hnでしか区切れない派
・divやhrでも区切れる派
・区切るものなんて無い派
の三つ巴？
どうでもいい派はこのスレにはいない？

>>142
俺は、「Hnは、そのブロック要素内のみ有効派」

またアンケート？

アンケートしてなんなの、多数派が正統なのか？
議論しろよ

アンケートは答えのないものが対象だからいいんでないの

どの説も決定打はなしですか。

中身がどう、区切りがどうなんて閲覧者は意識しない。してるのは書いた本人だけ

それをいったら見た目優先マークアップ二の次で
Strictスレがなりたたくね？

148はたまたまこのスレに迷い込んだだけ

HTMLに注釈をマークアップする要素が無いことに積極的な意味があると考えるならば、
ハイパーリンク、cite属性とかabbrのtitle属性などを使い分けるべきなのかなと思った。

あと、Wordで脚注を付けてHTML出力すると、<hr>で本文と分離され、<div id=ftn1>、
<p class=MsoFootnoteText>で囲んで脚注が記述される。そして、脚注と本文
の間には相互リンクが張られる。idのftn1は特定の書式とは関係づけられていない。

注釈がどの場所に記述されるかは文書の構造とは無関係な情報だと考え、さらに、
divがHTMLで実装されなかった文書の構造をマークアップするためにあるのだと考えれば、
脚注のマークアップとしては非常に適切なものじゃないだろうか。

dfn要素は？

未来の世界ではどうなってんの？
html5やxhtml2が繁栄している世界

HTML5だとaside要素が註釈エリアとして機能するのかな
articleとかsectionとかasideとかの関係がよくわかってないけど

>>142
仕様書を読む前の、前提条件の解釈の違いで派生しているのでは？
linkは何を示せるの？
anchor=参照、の意味合いは？
siteって何？
とか過去何度かでた話だよね

誰か早くまとめwikiやってよ
問題提起まとめるぐらいで良いからさ

>>155
どうぞ
http://wiki.fdiary.net/StrictHTML/

wiki何も更新されてないんだ
過去何度かでた話を知っている人が問題提起まとめるぐらいをやってくれたほうが

古参、とくに初期スレからの人はもういないのでは…

思いつくかぎり適当に書いてみた。

Strictスレとは直接関係ないがこのへんも参考になりそう。
http://www.akatsukinishisu.net/wiki.cgi?HTML%B5%C4%CF%C0%A5%EA%A5%F3%A5%AF%BD%B8%A4%CE%A5%EA%A5%F3%A5%AF%BD%B8

古参は古参を気取るためだけに登場して
役に立つようなことは何もしない

古参を気取るだけの奴を古参と、単に160が呼んでるだけだな
トートロジー

StrictHTML Wikiトップページ、
見出しとかつけて整理しといた

よくBlogとかのCMSで画像の右寄せとか
<div class="右寄せ">
<img 省略>
</div>

としてCSSで右寄せにしてるけどdivなんて使わずに
imgだけでやったほうがええのか？

img はインライン要素

画像の部分が文書構造から見たときブロックレベルであるならdiv要素で
囲むのもありだと思う。class="右寄せ"はだめだが。

>>163
IEはimgにfloatしてもぴったりとくっつかんだろ

スキル不足のうえにスレ違い

普通にくっつくし。

たまに剥かないとはがれなくまります

俺普段は<p><img /></p>なんだが、
画像だけ独立した段落として扱っていいものか？
もっとも関連あるパラグラフに画像つっこんで
<p><img class="fig"/>...本文...</p>
img.fig {
　display: block;
　margin: ... ;
}
とかの方がいいだろうか？

http://code.google.com/p/blueprintcss/
googleで配ってるCSS frameworkを見てみるとそういうマークアップを前提にしているっぽい
けど
画像が図形などの場合はテーブルと同等の扱いをしたいので俺は
<dl>
<dt><img></dt>
<dd>imgのcaption（tableのcaption的なもの）</dd>
</dl>

いいのか悪いのかわからないのでえらい人待ち

このように過剰にdivを避けるのも、div厨の一種。

別に過剰にdivを避けてるわけじゃなく
本文中ならdivよりpかdlとかのほうが適切だと思うだけだが…
見出し階層の構造化のためにdiv使いまくりだし。

>>171
ただのエロい人だけど、キャプション付けたいんなら別にそれでいいんでない。

>>171
画像のキャプションのことじゃなく本文のつもりだった。
普段は、
　<p>段落</p>
　<p><img /></p>
　<p>画像に関係ある段落（キャプションじゃなく）</p>
なんだが、これを
　<p>段落</p>
　<p><img />画像に関係ある段落</p>
とかすると、画像がどの段落に関連してるか示せるかな、という。

XHTML strictでリンク先を別窓で開くようにしたいのですが
strictだとtarget="_blank"が使えないのですが方法はないでしょうか？
jsを使わなくても出来る方法は無いでしょうか？

>>176
「別窓で開く」という思想自体がstrictではない。

もう5年くらい待て

つまりは>>37

>>177
その考えは分かってはいるのですが外部リンクで地図サイト（ＭＡＰＦＡＮ）等に
リンクを貼った場合、リンク元ページは残したいというのが理由で書きました。

「リンク元ページは残したい」という思想自体が

ユートピア

>>180
外部リンクだからといって、新しいウィンドウを開かれたら、うざいだけ。

というか、携帯とかDOS画面みたいな1画面しか表示できない端末で見てたらどうするの？

分かってたらこのスレでそんなこと訊かないよな。

<a href="./example.html">内部リンク</a>と<a href="http://example.jp" class="outside">外部リンク</a>
とかマークアップして、あとはスクリプトでやるしかないな。

新規ウィンドウに対応する各ブラウザのショートカットキーを載せておけばいいじゃない

divタグを使ってのグループ化という事でお尋ねしたいのですが

<div id="navi">
<ul>
<li>企業情報</li>
<li>ギャラリー</li>
</ul>
</div>

<div id="contents">
<h2>会社概要</h2>
会社概要の内容
<h2>沿革</h2>
沿革の内容
</div>

こんな場合、h2の二つの項目もそれぞれ別々にdivタグで囲むべきでしょうか？
<div id="contents">で囲まれてるからこのままでいいのか、やはり内容別に一つ一つをdivで区別すべきなのか
その辺の解釈で悩んでいます

自分で地図作れば解決

divによるグループ化自体
結論が出ていなかったような

最近同じような質問を見た気がするけど、
デジャヴだろうか。

>>189
形成していく上でもdivが必要無くても
グループ化という事で内容別にdivで分ける必要があるのかな、と

>>190
随分前に別の質問させてもらいましたが、この事では初めてです

ここまでやるべき

<div id="contents">
　　<div class="content" id="kaishagaiyo">
　　　　<h2>会社概要</h2>
　　　　会社概要の内容
　　</div>
　　<div class="content" id="enkaku">
　　　　<h2>沿革</h2>
　　　　沿革の内容
　　</div>
</div>

>>187
そんなの自己満足の範疇だから好きにすればいいよ
CSSなりでのデザインの都合で付けるなり付けないなりすればいい

div 自体何の意味づけも無いから Strict という点から言えば
div で囲もうがコメントで区切ろうが無関係

>>191
> グループ化という事で内容別にdivで分ける必要があるのかな、と
なんでそんな必要があると思ったの
必要があるとかないとかじゃなくて「俺はこうしたい」んじゃないの
だったらこのスレで聞かなくてもお好きなように

別窓云々は都度選択出来るようにすればよくないか？もちJavaScriptだが

俺は<hn>の有効範囲がそのブロック内のみと思っているから、
ひとまとまりの内容を表すのに<div>でくくる。

じゃあ俺はそんなこと思っていない

<div id="navi">
<ul>
<li>企業情報</li>
<li>ギャラリー</li>
</ul>
</div>

こっちの方が気になった。ul#naviでいいじゃない。

さきほど別窓で質問したものです。
ご回答ありがとうございました。別窓はやめたいと思います。ところで
画像置換でギルダー・レビンメソッドよりお勧めのものってありますか？
現在作っているサイトで使っているのですがいらない<span><span/>が
気になります。これを解消した方法はまだ出てきていないのでしょうか？

なぜこのすれなの
しつもんすれがあるじゃない

>>199
img要素

Webサイトデザインを省力化--CSSフレームワーク「Blueprint 0.5」
http://japan.zdnet.com/news/software/story/0,2000056195,20355701,00.htm

>>171で出てるね
そしてcssはこのスレとはｋ

>>193
何の意味づけもないってのは事実誤認だな。
　<div><p>...1...<p>
　<p>...2...<p></div>
　<p>...3...<p>
と
　<p>...1...<p>
　<div><p>...2...<p>
　<p>...3...<p></div>
は文書の構造が違う。
HTML類は入れ子構造が作れないから、この違いは大きい。

ただ、このような「文書構造上異なるグループ化」はできても、
それが「段落集合のグループ化」とかいう意味になるとかはないけどね。

「別窓で開きたい人は<kbd>Ctrl</kbd>を押しながらクリック！」
とかすればいいのにna

ストリクタ的にはcssで指定したら_blankで開けるようになったら問題ないんだろうな。
strictに準じてるから。

>>206
なんというバカ

なんで表現を定義するCSSでリンクの扱いまで決めるんだよ
アンチスレか初心者スレに引っ込んでろ

blankで開くように指定するCSSなら別にあってもいいや
別のページで表示するっていうのはある意味見かけ的な動作と言えるし

結局ただのわがままの押し付け合いだからな。
別窓を製作者がユーザに強制してるところで、
製作者に別窓を押し付けるなと言いつつ自分がそれを押し付けてるだけ。
どっちの意見も間違っちゃいないのにお互いを完全に否定してるからな。
救えない。

UAが別ドメインへのリンクは新規タブORウィンドウで開くって機能を搭載して
くれればいいのにな。

だまってマウスの真ん中ボタン押して別窓開けや

なんか <a href="javascript:〜"> って書いて別窓だしてるページが嫌い。
リンクを別窓で開こうとしたら href がアドレスじゃないからエラーになるし・・・何考えてんだｗ

最近はJavaScriptで別窓を開かせながらも､ シフトキー + クリックや中クリックでもちゃんと開ける作りが増えてきましたね｡

定期的に沸くな、なんとしても外窓で開かせようとするヤツ
js使えばStrictのDTD選択していてもできます！とか死ねよ

自分は外部リンクを開くときはいつも新規タブに開くのだが、たまにCtrlを押
しそこねていることに気がつかず、うっかりタブを消してしまって「あ、しまっ
た」ってなるときがある。Operaはゴミ箱のアイコンから消したタブを復活で
きるので致命的ってこともないが、タブやウィンドウの復活機能がないブラウ
ザを使っている人って困ったりしないのかなと思う。そういう点では
target="_blank"にもメリットがあるんだが、外部リンクは新規タブやウィン
ドウで開いている人ってどのくらいいるのかな。タブブラウザならタブがたく
さん開いてもあまりうっとうしくはないんだが、SDIのブラウザだとタスクバー
がえらいことになるから、需要はかなり微妙なラインにありそう。

js で target 属性をつけるのはあかんと思うが、
onclick や ondblclick 等をつけての window.open なら許可してるゥゥ

それもユーザビリティに沿ったもんに限るけど。
ユーザーの行動の範囲を広げるのはいいけど、狭めるものであってはいかんな。

別サイトへの target="_blank" は優しいか
http://pc11.2ch.net/test/read.cgi/hp/1136738511/
【target="_blank"】外部リンクは別窓？
http://pc11.2ch.net/test/read.cgi/hp/1166901734/

せっかく隔離スレがあるんだからそっちでやってください

>>216
onclickを直に書くとHTMLのメンテが悪くなるから
外部のjsに書いたほうがえーよ

>>218
うん、そう言ったんだけど・・・、そう聞こえなかったかｗ

onclickもjavascriptの一種なのに
なんでonclickで新窓開くのは許可して
target属性指定するのはダメなんだ？
やり方が違うだけでやってることは同じだ

>>220
>>217

いや>>216の二重基準がおかしいなと思っただけで
俺は新窓云々には興味ない。

>>220
target属性の無いDTDが前提の話だからじゃない？
あれば直接書けば良いだけだし。

俺は >>216 じゃないが、この基準は分かるぞ。
仕様書には、スクリプトで生成後のソースも仕様に沿ったものでなければ
ならないとあるので、DTDに反するものを生成するのは完全に間違い。

DTDに反しなくても、「直接書くとストリクト的でないからスクリプトで
生成しよう」なんて発想はストリクトでない。直接書いてもスクリプトで
生成しても同じ仕様に合致しないとならないんだから同じ事。

一方、ソース（またはDOMツリー）を追加変更することなく、関数で機能を
付けるのなら、ストリクトは関係ない。アクセシビリティやユーザビリティの
問題となる。

>>214
別にいやなら見にこなくてもいいんじゃよ。
外窓で開かせようとするサイトもここも。

こういうやつらはそれでも来て文句言うだけ言いまくりそうだけど。

誘導されてるのにスレ違いの話題で粘着しつづける225の必死さ

ここで214登場

はい、おっぱっぴー

どうすべきか、であって
別窓で開きたいとか文字を消して画像にしたいとか
ああしたいこうしたいはスレ違い

どうすべきかなんて決まってるジャン。
target="_blank"を使うなってだけだろ。
あとはstrictの問題じゃなくなってるし。

だから「どうすべきか」という話題とは関係ない
target="_blank"の話はするなってだけだろ。

このスレをざっと読んで思ったのですが，dlが好んで使われているようですね。
個人的にdlはあくまで用語定義のリストととらえているので，
それ以外の目的に使用することには躊躇してしまうのですが，
strictな立場でも，dlの多用は許容されているようですね。
私の場合はclass分けしたdivを多用していて，それはそれで面倒なのですが‥。

definition listのdefinitionは定義じゃなく記述と訳すのが適切。
（「定義」ということ自体、対象について記述することだし）
dlを、用語と記述の2つの部分から構成されるリストとして考えれば
会話（<dt>名前</dt><dd>セリフ</dd>）などもstrictな用法。

>>233
ただ，dlの適用範囲をどんどん拡大していくと，本文においてもhnやpの替わりに
dlのdtやddを使えば良いという考え方が出てくる訳で，
それはdlの適用範囲を逸脱していると思うのですが，
dtにタイトル，ddに説明的な用法を認めるとすると，
そのような考え方が生まれても仕方ないのかなと思います。
そういうことを考えると，dlはあくまで用語定義リストに使用をとどめておくのが
明確で良いのではないかと思った次第です。

確かに会話もdlの例として見かけますね。
個人的にはtableと迷うところですが，dlの方が適切なのでしょうかね。

脚本のマークアップとかで
<tr><th>時間・場所</th><th>話者</th><th>セリフ</th></tr>
<tr><th>深夜・自宅</th><td>俺</td><td>「ぬるぽ」</td></tr>
<tr><th>早朝・ネット喫茶</th><td>誰か</td><td>「がっ」</td></tr>
みたいなのはアリだなと思うが、

<tr><th>俺</td><td>「ぬるぽ」</td></tr>
<tr><th>あいつ</td><td>「がっ」</td></tr>
<tr><th>俺</td><td>「ぬるぽ」</td></tr>
<tr><th>あいつ</td><td>「がっ」</td></tr>
みたいなのだとすると、間違った表の使い方だと思う。
tableで同じ対象を表す見出しが繰り返されるのはキモイ

なんというnot valid...訂正
<tr><th>時間・場所</th><th>話者</th><th>セリフ</th></tr>
<tr><td>深夜・自宅</td><td>俺</td><td>「ぬるぽ」</td></tr>
<tr><td>早朝・漫喫</td><td>誰か</td><td>「がっ」</td> </tr>

<tr><th>俺</th><td>「ぬるぽ」</td></tr>
<tr><th>あいつ</th><td>「がっ」</td></tr>
<tr><th>俺</th><td>「ぬるぽ」</td></tr>
<tr><th>あいつ</th><td>「がっ」</td></tr>

脚本にtableなんて論外だろ・・

>>235
> tableで同じ対象を表す見出しが繰り返されるのはキモイ

だとしたら，話者にthを使わず，tdを使って，class="speaker"属性を与えればよいのでは。

しかし，会話にdlを使うとしても，dtに同じ見出し（話者）が繰り返されることになりますが，
この場合は構わないのですかね。

おいおい言ってることが怪しくなってきたぞ

thは見出しだがdtは見出しじゃないんだが…

脚本・・・
dl の中に p 段落があるのは割と受け入れられるけど、
table の中に p 段落が入るとなると、違和感があるなあ。

>>241
> table の中に p 段落が入るとなると、違和感があるなあ。

本来はあるべきでないという次元の話と、現実に存在しているものなら許容せざるを得ないという話のせめぎ合い。

LaTeXだと、表中に複数段落が存在することも箇条書きが存在することも許容しない。
だとすると、こんな表はどう扱えばよいのか小一時間…

http://www.mext.go.jp/b_menu/kihon/about/06121913/002.pdf

dlと2列のtableの境界は結構曖昧だな
dlの強みは、tableよりも簡単にタグを組めることと、
dtとddを2段に分けて表現できることか
みんなあんまり考えずにdlを使ってるんじゃないの？

お前なんでStrictスレにいるの？

いよいよ言ってることが馬鹿丸出しになってきたな

煽るだけかよ
反論してくれよ‥

8.知能障害を起こす
　「何、犬ごときにマジになってやんの?バーカバーカ」

9.自分の見解を述べずに人格批判をする
　「犬が哺乳類なんて言う奴は、社会に出てない証拠。現実をみてみろよ」

これか

> 8.知能障害を起こす
> 　「何、犬ごときにマジになってやんの?バーカバーカ」

「何、HTMLとCSSごときにマジになってやんの?バーカバーカ」
http://d.hatena.ne.jp/amachang/20070807/1186485054

このスレは意味や構造に基づいたマークアップについて話し合うところなのだ
から、>>243は「dlと2列のtableの境界は結構曖昧だな」と問題提起をしたの
なら、dl要素とtable要素の意味的な違いについて論じるのが筋であるのに、
「dlの強みは、tableよりも簡単にタグを組めること」などとマークアップ作
業の容易さを比較したり、「dtとddを2段に分けて表現できること」と意味の
わかならい発現をしたりするものだから、>>244や>>255はあきれて物も言えな
いって思っているんでしょ。>>243の発現はこのスレの趣旨とは全く関係ない
ことなのだから、議論の余地はない、よって反論するまでもなし、ということ
では。

タイポ。発現→発言

個人的にあくまで主観です

自分がおかしいとはこれっぽちも思わないのなｗ
>>248みたいなの持ち出してきてるしｗ
経験からこういうやつは何を言っても無理やり理由を作って自分を守ろうとするんだよな。
かなり厄介。

記述内容が箇条書きと表形式のどちらに適してるかでdlとtableを使い分けるべき。
リストや表をマークアップするためにそれぞれ作られているのに、
タグを書きやすいから全部リストでやっちゃえ、とかは本末転倒。
もちろん、どちらに適してるかは主観的だが、ある程度は共通理解もあるはず。

たとえば表は、水平方向と垂直方向の見出しの掛け合わせで
次元（他に上手い言葉を思いつかない）を持たせられる。
　 a　b　c
A Aa Ab Ac　
B Ba Bb Bc
C Ca Cb Cc

箇条書きは、ネストすることで階層構造を表すことができる。
ごはんもの
　　チャーハン
　　　　400円
　　　　800kcal　
　　カレー
　　　　350円
　　　　700kcal　
麺類
　　うどん
　　　　250円
　　　　550kcal　
　　みそラーメン
　　　　350円
　　　　760kcal

と思うんだがどうか

> タグを書きやすいから全部リストでやっちゃえ、とかは本末転倒。
これは>>243の妄想なのでスルーしてもいいのに

>>253
表と定義型リストの違いがよくまとまってるな。
>>243がいかにものを考えてないかよく分かる。

ところで安い食堂だなｗ　学食か？

>>253
わかってるとは思うけど、ネストした階層構造は表組で表すこともできる。

tableは三次元の表も作れるしね
恐ろしい子

Tableはデータの比較や計算の際にわかりやすい。定義リストは説明を迅速に調べたい際に便利。
ただ紙媒体の場合、リストは文中でも使うけど、TABLEは「別表」とか言ってグラフ図に準じる扱い。
だから俺は日記やエッセイにTABLEがあると違和感がある。HTML以前に文章作法としてだけどね。

まあ確かに、日記とか随筆とかで表は書かないわなｗ
ブログとか論文形式のページには向いてるが

活字では表と同等な扱いのグラフ図を表現するにはImgやObjectのインライン要素なんだよなあ

学術用で始まったのにグラフ用の要素ないんだよな…

<graph title="時間-電圧曲線">
<axisx mode="log">time / s</axis>
<axisy mode="linear">Voltage / V</axis>
<wave name="wave1">
<value axisx="0" axisy="0" />
<value axisx="10" axisy="5" />
</wave>
</graph>

みたいな。手書きだと悶絶しそう…画像ですむか。
将来的にはSVGとかMathMLとかになるのかな？

あくまでテキストのマークアップだからだろ

それもそうか…

表現したいことが簡単に表現できないからな
HTMLとか時代遅れな技術になってる希ガス

時代はXML

>>234
> ただ，dlの適用範囲をどんどん拡大していくと，本文においてもhnやpの替わりに
> dlのdtやddを使えば良いという考え方が出てくる訳で，

dlはあくまでリストだから、本文として用いるのは不適切だよね。

dlはあまり使ったことがないけど、
他の人の使い方をみると、dtを見出し、ddをその内容のように使っているのが多いかな。
HTML 4.01 Specificationのリストの例をみても、この解釈はあながち間違いではないように思う。
だとすると、dlを脚本に用いるのはおかしい気がするが、このdlの解釈は間違ってる？
どなたかご教授お願いします。

またきみか

とりあえず日本語でおｋ

dtは見出しではない。見出しが何を意味するか調べろ。
dlのdefinitionを定義ではなく記述として訳・解釈すると
定義リストのみならず、いわゆる対話や脚本なども
不適切な用法ではない。

節の区切りってhrでおｋ？
それともdivでsection風味にしたほうがいいのかな

このスレを読み直した上で
それを踏まえてもう一度レスを

blockquote中の見出しの件。
俺は2なんだが、どんなもんだろ

1. 引用先のマークアップをまんま使う。
　　自分のとこの見出しレベルとずれても気にしない。
2. <p class="headline">...</p>などと置換する
3. そもそも見出しまで含むような引用はおかしい。
　普通の本の引用でいうと、1節まるまる引っ張るようなもの

３で・・・って思ったけど
文字を大きくするためだけに見出し要素を使っているサイトとかの引用は・・・
って引用元のマークアップを改変してもいいか悪いかは結論出てる？

というかどっちもまとめwikiに表題だけ書いてあるね
過去ログ持ってる人、過去ログのアップロードかwikiの追記をお願いします

>>272
4. 引用した内部で最大を h1 にずらし、それに合わせて以下も引き上げる

だと思う。見出しは相対的なものなので(切り出した中で) h1 がトップであるべき
とはいえ手間の点で 1. にしちゃってるのが現状だけど

2. は法律での「引用」の前提条件を満たせなくなるので避けるべき
(少なくとも「原文での h? を p に置換」とか付記しないとまずい)

3. については、普通なら dl を使うような場面で見出しを使う Web ページは
たくさんあるし、それが間違っているとも言えないし、例え間違っていると思っても
「引用」である以上、原文が「見出し」としている所を改変するわけにはいかない
ので 1, 2. と等列に並べて考えられないと思う

>>274
「4.」は「原文でのhnをh1に置換」とか付記しなくてもいいの？

>>273
>って引用元のマークアップを改変してもいいか悪いかは結論出てる？

それは単純に法律の問題かと

意味が付随する h? とか ol/ul, dl, em/strong, cite, q/blockquote なんかはまずいけど
見栄えを整えるための div/span や id, class, style 属性なんかは取り去って問題ないかと

それと Strict にするためにそうではないページからの引用に必要最低限の要素の置き換えを
するのは許容されると思う(メディアの違いによる必要な処置だから)

>文字を大きくするためだけに見出し要素を使っているサイトとかの引用は・・・

引用内部で辻褄が合っている限りは内容に手出ししない方が無難かと
他人が見て明らかに「見出し」でないものに見出し要素を使っていても
それまで含めて「原文」なわけだし
気になるなら「(原文ママ)」と付記すればいいかと

>>275
見出しは相対的なものなので見出しのレベルを丸ごとずらしている限りは不要だと思う
(dl のネスト等と同じ扱い)

>>272
一節と言っても、数行しかない見出しと節のペアだってありうるわけで、べつにおかしかない。

で、そもそも、引用するのは文章であってマークアップのソースじゃないんだから
文意を曲げる意図を持った改変とかじゃなけりゃ、とくに問題とはならない。

論文を引用するのに、その論文の印刷媒体のフォントや強調効果などを、
まったく相違ないフォントの種類やフォントサイズ、強調時の太さ、などに
しなけりゃならない道理が（普通は）ない、ということと同じ。

あと、HTMLのマークアップは、その文書内で整合性を持ってなきゃダメ。
見出しレベルがおかしいとか、そういうのは（あたりまえだけど）アウト。

>>278で結論だな

元の文章が句読点のたびに<br>で改行してあるようなやつだったら、それもそ
のままにしておくべきなのかな。

著者が意図して改行している（と思われる）詩や散文みたいなものはそのままで
その他は気にしなくても良いんじゃないかなあ

>>280
著者が「意味段落」と「形式段落」で使い分けているようなら
その区分けは維持した方がいいと思う

p要素も何も使わず、全部brで書かれてたら…とか、色んな状況を想定して
みると、結局、著者の意図を変えないことが重要で、著者のマークアップを
変えないというのはあまり意味がないと思う。

実際、HTML文書の内容を紙メディアに転載する場合などは、マークアップは
全部除かれる訳だし。

>>274にすごい違和感を感じるんだが。
引用とはいえなんでh1がくるんだ？
ありえんだろ。

>232=234=238=243=274と考えるか
おかしい奴が複数人同時期に涌いたと考えるか
お好きな方をどうぞ

>>269
> dtは見出しではない。

>>274
> 普通なら dl を使うような場面で見出しを使う Web ページは
> たくさんあるし、それが間違っているとも言えないし、

dtはddの見出しか見出しでないのか、どちらでしょうか？


>>269
dlを定義リストではなく、記述リストと解釈したとして、
ddをdtに関する記述と意味づけるとすると、
dtに人物名が入れられた場合、
ddにはその人物に関する記述（人物紹介）が内容として入るべきであって、
その人物のセリフを入れることができると解釈するには少し無理があると思うのですが。
よかったら、もう少し詳しく説明してもらえませんか？

> 見出しが何を意味するか調べろ。
何を意図している発言なのか良く分かりません。
段落に対してしか「見出し」という用語は用いないということでしょうか。
thの"h"に当たるheaderも「見出し」と訳されているように思うので、
dtはddの見出しであるという表現に問題はないように思うのですが、
不備があればご指摘願います。

仕様書すら知らない初心者が知ったかぶりするスレじゃないんですが

いやもうさ、そんなにtableでやりたいならそうすればいいよ

何だか引用したくなくなってきたよ・・

全員、
妄想じゃなくてどこを参考にしたか書いてください
それとも自分の思い込みが絶対だと言うのですか

>>286
HTMLの仕様ではdlを脚本に用いることは認めているんだよね。
"10.3 Definition lists: the DL, DT, and DD elements"の最下部を参照。
http://www.w3.org/TR/1999/REC-html401-19991224/struct/lists.html

定義リストがどう転んだら脚本に応用でいるのかは俺には説明できないが、
仕様が認めているのでdlは脚本として使用できるとしか言えない。

dlの使用例についてはこれを参考にしてみては。
多少やりすぎかもしれないが、何か分かるかもよ。
http://www.cybergarden.net/revolution/20060706/
42ページ以降にいろいろ載っている。
まとめのページにはトンチンカンなことも書かれているが、参考までにどうぞ。

>>291
>応用でいる
応用できる

そもそもthって見出しじゃなくて項目名だろ。
ラベルとかそっちに近い。

意味・定義にはdfnあるんだから、dlは記述型リストとして広く解釈すればいい。
絶対に定義にしか使えないリストなら（まあ「定義」の解釈にもよるが）
「他の応用としてdialogue（対話）にも使える」などと書かれるはずがないし。

過去ログはどこで手に入りますか？

strict-html 29 とかでぐぐれ

質問者は最初の質問番号を名前欄に入れてくれよ
なんというカオスだよ

というかそもそもdtがddの見出しだなんて誰も言ってないんじゃ。

>>274はdtを使うべき場面で見出しを使っても間違っているとはいえないといっているだけで
むしろ見出し+p/ul/olがdl(dt+dd)的な使い方も出来るという意味に取れる。

過去ログの初代スレッドで下みたいなのあって吹いた
2001年ってそんなころだったのか…

＞　もうね、<strong>アホか</strong>と。<strong>馬鹿か</strong>と。
＞　<q>よーしパパ特盛頼んじゃうぞー</q>、とか言ってるの。もう見てらんない。
＞　<dfn>つゆだく</dfn>

属性値はダブルクォートでしか囲ってはいけないんでしょうか？
シングルクォートを使いたいのですが、これはまずいんでしょうか・・・

なぜシングルクォートを使いたいのか、理由を述べなさい

>>301
サーバー再度スクリプトで書きにくいから。

書きたければ書けばいいじゃないか、シングルクォート。
いいと思うよ、うん。誰も止めない。

正確に言えば、あなたのソースコードをシングルクオートに対応してない
ヘボプログラムに食わせる人や、そういう人の影響（被害？）を被る
人は止めたがるかもしれない。

しかし、スレ的には何の問題もない。

つかこのレベルの質問する時点で…

すいません理由を書くべきでした。

PHPでHTMLのタグからすべて出力するようにしているので、
スクリプト中のダブルクォートとかぶってしまうときがあるんです。

>>304
ブラウザが対応していないという意味でしょうか？

>>300
もういいよphpスレか初心者の質問スレいけよ低脳

初心者スレならダメでFA。

web制作板でここ以外になんか面白いスレある？

>>309
オレの日記帳
http://pc11.2ch.net/test/read.cgi/hp/1148511884/

>>309
JavaScript

javascript質問スレ覗いてきたが、凄いな…
js多用してるのでoffの人はエラーページしか見せたくないとか
ページを閉じたときに効果音鳴らしたいとか

>>312
あれはよく出るアホな質問の一つ。
みんなスキル高いから質問によってはなかなか面白い

質問スレは基本的に酷い質問しかこないから面白いのは少しだけだろ
あとあそこ意味もなく国語問題で揉めたり
回答者の一部が無駄に威圧的問題で揉めたりするし

昔JSスレで質問に答えたりしてたけど、流れが早いから最近面倒になって行かなくなったなあ・・・。
strictスレの早さはかなり楽。
旅行で1週間とか開けても追いつけるし。

>みんなスキル高いから質問によってはなかなか面白い
寝言は寝て言え

>>316
こっちまで出てくんな

>>317
おまえもだ

>>316
>>318

m9(^Д^)

>>317
>>319

m9(^Д^)

何この流れ…必死なやつがいるな

まず自分で調べもせずに馬鹿な質問（しかもマルチ）して突き返されて揚句の果てに「寝言は寝て言え」

そんなことよりGRDDL勧告ktkr
プロフィールとかに早速使おうかな（ミーハーだが）

http://bizmakoto.jp/makoto/articles/0709/13/news036.html
ブラウザの文字サイズ最大にしてる人が50%近くいるそうだ
（あくまで子育てサイトでの統計だから一般化しにくいにせよ）

よくある豆字サイト対策で最大にしてるんだろうが、
中サイズで16px前後、もちろん可変でCSS書いてる俺のとこは
一体どれほどでかいフォント表示されてるんだろうかと考えて凹んだ
あんまり大きすぎると今度はみっともないし

まあ見てる人の自由だけどさ……

明らかにスレ違いなわけだが

GRDDLもXML系スレ行き？

スレ違い承知でレスするけど、その「こそだて」にアクセスしたら豆字固定で噴いたｗ

あんま関係ないが、font-size:95%で書かれてるサイトが結構あるけど、
IEだと最小にしたときに文字が豆になって潰れるから96%で書いて欲しい。
96%なら最小にしても小のときとほぼ同じだから助かる。

あんまどころか全く関係ないな

>>326
このスレで何度も話された、div,span要素に係るclass,id属性による意味付けについて議論が変わる。
GRDDL処理を前提にclass属性、id属性を付けると考えると、属性値を何にするかしっかり考えるよ。
あとGRDDLの勧告に従うと(X)HTML勧告外のLINK形式が必要になるが、このスレ的にはどうだろね？

>>330
どうだろねもなにも、ちゃんとプロファイル用意されてるじゃない

kanzaki氏のとことかにあるね
俺は前々から使わせてもらってたので
今回の勧告受けても特にネタにできず

stricter的には、

<dl>
<dt>A</dt>
<dd>B</dd>
<dd>C</dd>
</dl>

と

<dl>
<dt>A</dt>
<dd><ul>
<li>B</li>
<li>C</li>
</ul></dd>
</dl>

は、違ったものなの？
たまに使い分けているサイトを見かけるんだけれど、
その法則性が全く見出せない。
教えてエロい人

法則性って言われても場合によるし
その使い分けの内容を見ないことにはなんとも

>>333
stricterって何？

> たまに使い分けているサイトを見かけるんだけれど、
そのサイトの人に法則を聞いてみては？

気分だろ。
意味的には同一だし。

>>337
一緒じゃないと思う。

>>333
<DT>に対する二つの説明の関係性が全く違うときと、
説明が関連のあるリストのとき。

<dl>
<dt>インターネット</dt>
<dd>複数のネットワークを相互に接続して云々。</dd>
<dd>大阪にある音楽ソフト等を開発している会社。</dd>
</dl>

<dl>
<dt>検索サイト</dt>
<dd><ul>
<li>Google</li>
<li>Yahoo!</li>
</ul></dd>
</dl>

>>338
下の例を
<dl>
<dt>検索サイト</dt>
<dd>Google</dd>
<dd>Yahoo!</dd>
</dl>
と書くのでは、何か違いが出るかな？

ddは説明を内容として持つから
名詞だけってのは説明として不十分で違和感がある

自分は、複数の異なる説明のときはdd並列で
名称を羅列するなど箇条書きのときはdd内にulかol

> 名称を羅列するなど箇条書きのときはdd内にulかol
は説明として十分で違和感はないのか

>>341
<dd>説明<ul>...（補足的なやつ）...</ul></dd>
みたいなとき

箇条書き以外の追加条件を後出しかよ

その場合は
<dd>説明<ul>...（補足的なやつ）...</ul></dd>
とするより
<dd><p>説明</p><ul>...（補足的なやつ）...</ul></dd>
とするほうが匿名ブロックボックスができないから「違和感がない」

で
> <dd>説明<ul>...（補足的なやつ）...</ul></dd>
の「説明」の部分がなく「dd内にulかol」だけのときは
説明として十分で違和感はないのか

匿名ブロックってそんな気持ち悪い？(´･ω･｀)

2.0 で P の中に UL とか入れられるようになった場合は違和感なくなるんかな。

一方HTML5じゃdivやliにはブロックレベルとインラインレベルの混在はできない
とまあ2.0だの5だの未来の話をしても

>>339
箇条書きを単発の文章を複数で書いていいのと同じで、それでもいいけれど、
ただその例だと、検索サイトとして、Yahooがある。Googleがある。と言うのがわかるだけで、
「検索サイトのリスト」ではないので、YahooとGoogleの関連性は全く保証されない。

>>338では、「検索サイト」の説明として、「色々ある検索サイトのリスト」を示した。

「検索サイトとして、Yahooがある。Googleがある。」と「検索サイトのリスト」は
等価じゃないのか？
どちらも検索サイトの一部でしかないし、
検索サイトのリストも関連性という点では不明瞭なのは同じ。

>>347
それを等価だと感じるのなら、等価というしかない。

記述名に対する内容が、二つの独立した要素を持つ場合、
記述名が同じだけで、互いには関係の無い別物を表している。

記述名に対する内容が、一つの内容の中にリストという要素の場合、
ひとまとまりの列挙として説明される事柄である。

全て主観に基づいた俺ルールです

標準化への道程は長く険しい

ギャラリー風に画像を並べて表示したいのですが

□ □ □ □ □
□ □ □ □ □　←こんな感じ
□ □ □ □ □

この場合はliを使ってもいいのでしょうか？
ご教授願います。

ごめんなさい。imgをCSSで制御していいようでした。
失礼しました。

>>351
sage ろよ……

それはそうと、別にリストを使ってもいいんじゃないか？

sage忘れてごめんなさい。
リストもありですか？色々ご意見を聞いてみたいです。

リストいったく （何故か変換できない） だと思ってたわ

まあ 「＞表示したいのですが」 って言ってる時点でスレちｇ

アフィリエイトのURLも&を&にしてるのか？

>>348
リストを過剰にグループとして見すぎというか、その辺で混乱してると思う。

互いに関係のない別物を表してたとしても、
それは記述名に対する内容を表すものとして、リストで問題ないしリストだよ。
リストってそんな半端な制限された物じゃない。

話は変わるけど、リストは何のリストかという関連性があってこそリストなんだから、
dl-dt-ddってlリストをほぼ内包してるんだよな。
まあolみたいに順番が保持される必要とかがあるとまた違ってくるけど。

<ul title="hoge">
<li>magemage</li>
<li>mogemoge</li>
</ul>
≒
<dl>
<dt>hoge</dt>
<dd>magemage</dd>
<dd>mogemoge</dd>
</dd>
って感じかねぇ。

dd要素とli要素が同等であるというのはまあいいとして
title属性がdt要素と同等のパゥワァー！があるというのは納得いかない

意味づけの強さという点では確かに微妙だけど
確かにulにおけるtitleとdtは方向自体は似てるとは思うわ
必ず存在しないといけないdtと、
意味づけ的にまとめるくくりがあるだろうと推測されるulのtitleって感じか

そう考えるとlistにはtitleって必要だよな

必須属性じゃあるまいし。
どうしてもそういう方向に持って行きたいようだが。

さすがにそれは邪推し過ぎじゃないか

>>357
<ul title="hoge">
<li>magemage</li>
<li>mogemoge</li>
</ul>
≒
<dl title="hoge">
<dt>magemage</dt>
<dd>magemageの説明</dd>
<dt>mogemoge</dt>
<dd>mogemogeの説明</dd>
</dd>
となって似て非なるものだと思う。

教えてくれ(´･ω･｀)

縦に長い長い表（TABLE）があって、
項目がわかりづらいから、途中にも THEAD みたいなヘッダを起きたいんだけど、
TABLE の DTD って

<!ELEMENT TABLE - -
(CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)>

こうなってて、THEAD は 0 か 1回 しか置けないじゃんね。
こういう場合、みんなどうやっているんだい？(´･ω･｀)
複数置ける（はず）の TBODY で <tbody class="head"> とかにして仕方なく代用するくらい？

>>362
うむそれだ

どうやるも何も，1TABLEに 1THEADで十分だろ
項目が変わるんなら，別にするし，
見かけ上長くなって途中にも見せたいっていうならスレ違い

>>363
TFOOT にも THEAD と同じものを置いて以上
ブラウザの実装がまともなら見えている範囲の上端と下端に
それが表示される建前

今主流の現行ブラウザでそういう表示をさせたい、という話なら
JavaScriptのスレにでも行って相談すればいいと思うよ

カレンダーをテーブルでマークアップすることはストリクトですか？

>>367
表形式のカレンダーなら表だろ。
聞くまでも無いと思うんだが。

>>368
レスどうもです
その上で、
データセルに日付けだけではなく六曜や予定などを添えたい場合は
どうマークアップすればいいですか
ttp://www.kanzaki.com/docs/html/tbl-access.html#headers
こういうことをしたりするものですか

音声ブラウザに対応してるわけ？
strict関係ないだろ。

何に対するレスかわからんけど、
音声ブラウザが対応しているかどうかなんて音声ブラウザの実装の話であって、
実装の話は10中8, 9スレ違い。

>>369のリンク先の話についてなら
axis属性やid属性やheaders属性やscope属性によって各セルを関連付けられる。
しかし音声ブラウザが対応しているかどうかなんて（略）

dt要素にa要素を付加して
より詳しい情報をリンク先のページに書く
というのはストリクトではないですか？
dt要素に対応するdd要素に全て書き込むべきですか？
img要素のlongdesc属性みたいなつもりなんですが

<dl><!-- （０） -->
<dt>用語</dt>
<dd>（詳しい説明をここに全て書く）</dd>
</dl>

<dl><!-- （１） -->
<dt><a href="詳しい説明.html">用語</a></dt>
<dd>（簡単な説明）</dd>
</dl>

<dl><!-- （２） -->
<dt>用語</dt>
<dd><a href="詳しい説明.html">（簡単な説明）</a></dd>
</dl>

<dl><!-- （３） -->
<dt>用語</dt>
<dd>（簡単な説明）</dd>
<dd><a href="詳しい説明.html">詳しい説明を表示する</a></dd>
</dl>

（０）は普通のやつなので当然ありだと思いますが
（１）（２）（３）それぞれありかなしか教えてください
また「詳しい説明.html」が「#詳しい説明」（ページ内リンク）だった場合は
ありかなしか変わってきますか？

>>372
わざわざ別リンクで説明するのなら、ここでDL要素なんて使わずに、普通に
その用語が出てくる文中に <a href="詳しい説明.html">用語</a> と書けば
いいだけのような気もするが…。

(1)も(2)もなんか違和感があるし、(3)は「表示する」という表現がStrictでない
と思う。俺ならこんな感じにするかな。↓

<dl>
<dt>用語</dt>
<dd>(簡単な説明)の意味。<a href="詳しい説明.html">用語詳説</a>も参照。</dd>
</dl>

URIであることは同じだから、ページの内か外かは関係ないと思う。

どうもです
文脈の用語にアンカーをつければいいだけですね
リストにしたい場合は
<ul>
<li><a href="詳しい説明１.html"><dfn>用語１</dfn></a></li>
<li><a href="詳しい説明２.html"><dfn>用語２</dfn></a></li>
<li><a href="詳しい説明３.html"><dfn>用語３</dfn></a></li>
</ul>
とかでしょうか

>>372
「詳しい説明を表示する」ボタン自体は説明でもなんでもないから、
それ単体をddの内容にするのは不適切じゃね？

373も書いてるように、「〜を参照しろ」という類の説明文ならddとしても
適切だろうけど、ナビゲーションのための機能でしかないものを
単体でdd要素にするのは不適切な気がするよ。

>>372
<dt><a href="詳しい説明.html">用語</a></dt>

ってした時点で、「その用語についての説明」 じゃなく、「そのリンク先のページについての説明」、になる気がする。

そんな機能はdtにもaにもない。

どうもdtとddって関連付けられている印象が沸かないんだよなあ

dlの中にdt一つだけ（ddはいくらでも）とか
labelのforとフォームコントロールのidとの関係
みたいなのがいいなあ

※下記情報もごらんください。
○○概略〜○○の概略です。
○○について〜○○のについての説明です。
○○の効果〜○○はこのような物に効果があります。
○○の使い方〜○○の使い方の説明です。

とする場合正しいコーディングはどうなるのでしょうか？
〜の左側は別ページへのリンク
〜の右側はそのリンク先の説明

<li>や<dt>の使い方が上記で出てますが覚えてる最中なので
よく分からない面があります。ご指導よろしくお願いします。

>>379
Webサイト制作初心者用質問スレ Part 187
http://pc11.2ch.net/test/read.cgi/hp/1188989641/

初心者向けのスレはあっちの方

あっちでは解決済み。この上何を聞きたいんだか。

時間を見たらこっちで先に質問したようだけど。

誘導にしたがって初心者スレでご回答いただきました。
こちらにも一言書いておくべきでした。
大変失礼いたしました。

そうかねマルチ。

誘導されて移動した奴はマルチとは言わんぞ

＞こちらにも一言書いておくべきでした。

済みませんが質問させてください。
現在Firefoxを使用してサイトを作成しているのですが、tableタグの内容で
不明な点があります。

<table cellspacing="0" cellpadding="0" border="0">
<tr><td><img src="./pazuru_img/11.jpg" alt=""></td><td><img src="./pazuru_img/12.jpg" alt=""></td></tr>
<tr><td><img src="./pazuru_img/11.jpg" alt=""></td><td><img src="./pazuru_img/12.jpg" alt=""></td></tr>
<tr><td><img src="./pazuru_img/11.jpg" alt=""></td><td><img src="./pazuru_img/12.jpg" alt=""></td></tr>
</tr>
</table>

というタグを設定しているのですが、画像の横にはスペースが入らないのですが、
画像の下にスペースが入ってしまいます。
このスペースは消すことはできないのでしょうか？

>>387
CSSスレへどうぞ。

>>388
ありがとうございます。
移動します

<h3>contents navigation</h3>
とかアリ？ナシ？
ナシだよね？

コンテンツに含まれるのかナビって？
websiteっていうメディアを考慮すると、ナビさえコンテンツになるとかないよね？

ナビってどういう意味で言ってんの？

そりゃ、普通は Table of Contents とか言うけど
ここは英語の意味のスレじゃないので他でやってほしいな

何を言いたいのかわからんが、
目的と一致するならナビはそれだけでコンテンツになると思うが。

目次やナビのページなら目次やナビはコンテンツ。
普通のページに補助的に置いたナビとかなら、自分は見出しは使わないなー。

毎回画像は一つなのにたまたま一個だけたまたま一個だけ
と自分に言い聞かせてul,liで包むのは過剰包装な気がしてきた

コンテンツってどういう意味なんだろう。辞書には「内容」や「中身」ってあ
るけれど、ちょっと違うような。

うぃきぺでぃあればでてくる。
そういう概念ができたのが最近だから、昔ながらの日本語にはうまくあてはまる単語がなかったんじゃないかと。
情報の主体、とかそんなニュアンスだろうか。

「内容」で納得のいかない理由が理解できない

ニュアンスというか語義の範囲が違う。

それをもっと明確に打ち出してください。

いい加減スレ違い話はよそでやれ

そんなことよりブラウザゲーやろうぜ

商品の画像
商品名
商品説明
といった部分タグ付けをして

自分のタグ付けは
<ul>
<li><img商品の画像><li>
<li>
<dl><dt>商品名</dt><dd>商品説明</dd></dl>
</li>
<li>同構造で次の商品ー
このように考えていましたが

参考に似たようなサイトを探したら、同じ構造でこういったページもありました
<ul>
<li>
<p><img商品の画像></p>
<dl><dt>商品名</dt><dd>商品説明</dd></dl>
</li>
<li>同構造で次の商品ー

この二つのパターンはお互い意味合いは違ってくるのでしょうか？未熟な為違いは感じられないのですが
または明白にどっちかがが正しいといった事はありますか？

明確な間違いがあるかどうかは知らんが、感覚的に前者は気持ち悪いな。
li 要素ごとにひとつの商品で完結してた方が俺はすっきりする。
前者だと li 要素の中身が順番に画像・商品概要・画像・商品概要…ってなるわけでしょ？
各 li 要素にいち商品の説明全部詰め込んだ方が要素単位ごとに統一されてすっきり。

>>404
仰る通り後者の方がスッキリしてるというのは自分でも感じました・・・
ただ今まで似たようなパターン構造を前者のような作り方をしてきってました
構築的にもスッキリするし考え方を改めた方が良さそうですね、ありがとうございました

<dl>
<dt>商品名１</dt>
<dd>商品の画像１</dd>
<dd>商品の説明１</dd>
<dt>商品名２</dt>
<dd>商品の画像２</dd>
<dd>商品の説明２</dd>
</dl>

<table>
<tr><th>商品名</th><th>商品の画像</th><th>商品の説明</th></tr>
<tr><td>商品名１</td><td>商品の画像１</td><td>商品の説明１</td></tr>
<tr><td>商品名２</td><td>商品の画像２</td><td>商品の説明２</td></tr>
</table>

>>406

だろうね

>>403

はどっちも気持ち悪い

>>403
ulは順不同リスト（順序に意味がないことを明示したリスト）なんで、
個々の「商品の画像」と「商品名・商品説明」は対応付けされない。
なので前者は間違い。

dlは定義リストなんで、リストじゃない物をdlでマークアップしてる
時点で後者は間違い。（dlは、「定義orリスト」ではない）

これはおｋ？

<ul>
<li>
　　<dl>
　　　　<dt>商品名１</dt>
　　　　<dd>商品の画像１</dd>
　　　　<dd>商品の説明１</dd>
　　</dl>
</li>
<li>
　　<dl>
　　　　<dt>商品名２</dt>
　　　　<dd>商品の画像２</dd>
　　　　<dd>商品の説明２</dd>
　　</dl>
</li>
</ul>

・・・まあ自分もテーブル使いそうだが。

DLをわける理由もわからないしそれをさらにULで包む理由もわからない
単なる装飾のための過剰ラッピング？

<ul>
<li>
　　<dl>
　　　　<dt>商品名１</dt>
　　　　<dd>商品の説明１</dd>
　　</dl>
</li>
<li>
　　<dl>
　　　　<dt>商品名２</dt>
　　　　<dd>商品の説明２</dd>
　　</dl>
</li>
</ul>

で写真はddの背景に

ばかじゃね

>>411
>写真はddの背景に
写真は"前景"にすべきだろ。

何が初めましてだ、ぬけぬけと。板違いのクソ馬鹿野郎。

誤爆失礼しました

何が失礼しましただ、ぬけぬけと。

クソ馬鹿野郎。

<p><code>img</code>要素には、<code>alt</code>属性と
<code>src</code>属性が必須とされています。</p>

こういうcode要素の使い方って変ですか？(HTML 4.01の仕様書はsamp要素で
要素名や属性名をマークアップしていたりするのですが)

別によいのでは？

ただこの場合、「img要素」が一つの単語であって、
コード(HTML)としてもimgをさしているわけではないので、
別にcode要素としてマークアップしなくてよいのでは？　と思う

>>419
どうもです。「img要素」の「img」自体はHTMLのコードではないものの、HTML
のコードの中で指定する要素型名であることを示したかったので、使うべきか
どうか迷っていたのですが、code要素を使うことにします。

>>420

そういう意図があるんならcode要素でいいんじゃない？
その辺は裁量かと

どのレベルの見出しの下にも共通して登場するような見出しはどうやってマー
クアップするのがいいんでしょうか。例えば
-------------------------------------------------------------
1.img要素
　img要素は文書中に画像を埋め込むのに使う要素です。
[補足]
　object要素を使っても画像を埋め込むことができます。
1.2 alt属性
　alt属性によって代替テキストを示します。
[補足]
　longdesc属性を使って画像についての詳しい説明のある文書のURIを示すことができます。
-------------------------------------------------------------
こんなので、[補足]をどうするべきかということです。いくつか考えられますが、

・一つ下のレベルの見出しを使う
　　　→[補足]の重要度はどの見出しの下でも同じなのに、見出しレベルが異ってしまう
・dl-dt-dd要素を使う
　　　→dtは見出しではないのに代わりに使ってよいものか
・<div class="heading">などとする
　　　→[補足]がブロックレベルであることしか示せない
・h6要素にする
　　　→見出しによる文書の構造が崩れる

どれも微妙だなと思います。dl-dt-dd要素でごまかすしかないのかなという気がするのですが。

少なくとも補足は見出しにすること自体が微妙だと思うが

>>422

<h1>1.img要素</h1>
<dl>
　<dt>img要素は文書中に画像を埋め込むのに使う要素です。</dt>
<dd>[補足]<br />
　object要素を使っても画像を埋め込むことができます。</dd>
</dl>
<h2>1.2 alt属性</h2>
<dl>
　<dt>alt属性によって代替テキストを示します。</dt>
<dd>[補足]<br />
　longdesc属性を使って画像についての詳しい説明のある文書のURIを示すことができます。</dd>
</dl>

>>422
他の段落と同様にp要素として、titleにでも「補足」と書いておけば済む話だと思うよ。
>　　　→[補足]の重要度はどの見出しの下でも同じなのに、見出しレベルが異ってしまう
セクション自体の重要度が異なるなら、補足の重要度も異なるんじゃね？

>>424
これはひどい

>>422
例が 「補足」 とかなのでアレなんだが、
見出しを使うまでもないけど、そのブロックの caption や label みたいなの付けたいときはあるよね。
あるリストの名前とか・・・。

「補足」 程度だったら、文章の中にインラインで書いてもいいじゃん、っては思うけど。

上位要素で付けた lang 属性を下位要素で無効化する方法って定義されてるんでしょうか?
一応 lang="" としてやれば IE 的には解除されたような動きをしてくれるんですが。

<div lang="ja">
… 日本語の文章
<span lang="">その一部にだけ任意の言語が</span>
…
</div>

↑ちょっと単純ですが、要素の階層が深いので該当箇所だけ </div>任意の言語<div lang="ja">
と解除することが出来ません。また該当箇所だけ本当に任意なので (混在の可能性も) 付け直す
ことも出来ないんです。

<html lang="ja">
...
<p title="日本語" lang="en">English</p>
って正しいマークアップなんだろうか？

>>427
とりあえず、lang属性が空なのは不正。そもそも任意とはどういう状況？
<textarea>とかか？

>>428
開始タグの中もその要素の中だから、正しくない。

>>429
基本的に文章自体は日本語なのかどこの言語なのか決定できるんだけど、その一部に人名などで
任意の言語が混じるんですよ。あ、動的に生成されるページです。論文閲覧システムとかそんなものを
イメージしてもらえば良いかも。文章全体の基本言語が決まっていて、任意の言語が出現する場所も
分かっています。

IE で Wikipedia の左側にある他言語ページへのリンクを見ると 「・・・」 てなってる奴がありますよね。
lang="ja" と指定してる所にハングルが入ってたりするとああなっちゃうんですよ。

>>430
それはlang="ja"が原因ではなく、fontが入ってないだけなんでわ。

>>431
いえ、lang 指定外すか適切な言語コード指定してやればハングルでも何でも普通に表示できます (UTF-8)。
Wikipedia の「キムチ」のページのハングル表記は普通に表示できてますし、化けてる左側の多言語メニューの
違いと言えば lang="ko" を正しく指定しているかどうかだけでしかないですし。

まぁ lang 指定外せば良いんですけどね。解除する正式な方法があるならなぁと思っただけです。

アンタのPCの話されてもね。
lang指定どうこう言い切ったのはアンタなのに論点変えようと必死らしい。

別にlang指定どうこうから論点変わってるようには見えんが。

>>432
何も弄らなくても、左側メニューのハングルは化けないが。
lang="ja"のメインページの左側メニューで化けてるのは、スロバキアとトルコの間の国のみ。

>>433
いやローカルフォントの話振られたんでそれに答えたまでですが。
lang 範囲内に違う言語が混じると表示がおかしくなるのは定義的にかまわないとして、
じゃあ解除を正しく書く方法ってあるんですかね、というのは変わってませんが。

>>435
形からアラビア語かと思いましたがテルグ語という言語らしいですね。ウチでは見えてます。
ローカル保存して lang="te" 付けると表示されるかと思います (フォントがあれば)。

ブラウザによって挙動が違うんじゃないのか。
実装によって変わる話題ならこのスレの範疇ではない

>>436
その理屈だと、wikipediaでは化けてる国をクリックすればいいって事になるな。
lang="その国"になるんだから。
しかし実際はフォントが無ければ表示されない。
という事は、君が提示した<span lang="某国"></span>は役に立たないわけだ。
htmlはあきらめてpdfでも配布するんだね。

「言語不明」という言語コード und というのがあるから、lang="und" かな。

で、そもそもlang属性は「言語」を指定すると仕様書にあって、文字種の
指定ではないから、

<p lang="en">ヒー・イズ・ア・スチューデント。</p>
<p lang="ja">kare ha gakusei desu.</p>

このように、文字種ではなく、言語の方に合わせて付けるべきではないか
という議論もある。langで文字種がどうこう言うのはおかしいのかもしれん。

だいたい仕様書にも、「ユーザエージェントは、lang属性によって指定される
値に関わらず、すべての文字をレンダリングするよう、最善を尽くさねばならない」
と書かれている。フォントがないなら仕方がないが、langの値によって表示され
たりされなかったりするのは、仕様違反だと思う。

>>436
XHTML 1.1とかだとxml:lang=""で言語指定を解除できる
(XML 1.0 Third Edition以降でこの方法で解除できるように定義されてる)
HTML 4.01とかXHTML 1.0なら>>439だな

「解除」はどういうことを指しているんだろう？lang属性はデフォルトで
"unknown"になっているので、親要素で指定した言語を子要素で"unknown"
にしたいってことなら、それは無理な気がする。

あ、"und"ってのがあるのか。知らんかった。

少なくともモダンブラウザではlang属性が何であろうと他国語も表示される（フォントがあれば）。
IEは違うらしいが、元々仕様違反だらけなのは周知の事実。

433=438？
彼の言いたいことが全く理解できない。

無理に理解しようとしなくていいんだよ。

グリーンだよ。

und って 3 文字だけど ISO 639-2 じゃないの? lang に指定するのって 2 文字の 639-1 でしょ。
どっちでも良いんだっけ?

>>438
（´-`）.｡oO (この人 lang 属性に国指定しようとしてるんだろうか…)

>>439-
今まで 2 文字の言語コードしか見てませんでしたが 3 文字の ISO639-2 の方に Undetermined とか
Multiple languages、Miscellaneous languages なんかがありますね。調べたら RFC3066 で 639-2 の
3 文字言語コードも使えるようになったようです (現行 UA で正しく解釈されるかは不明ですが)。
>>439,440 で FA って事ですっきりしました。

長々とどうもありがとうございました。

>>448
もう一行目から意味不明だからなｗ

>>450,488
流れを嫁よ。読解力ねえったらありゃしない。
langで国指定？アホか。
>>436のlang="te"にすれば表示されるっつー御高説に反論しただけだっつーの。

> ローカル保存して lang="te" 付けると表示されるかと思います (フォントがあれば)。

　↓>>451 の反論

> その理屈だと、wikipediaでは化けてる国をクリックすればいいって事になるな。

>>452
意図的な抽出なのか、読解力の欠如か？
2行目も引用しなければ意味が通らないだろボケ。
＞その理屈だと、wikipediaでは化けてる国をクリックすればいいって事になるな。
＞lang="その国"になるんだから。

言語から何で国の話に飛躍してんだこのゆとりは。

>>454
だからwikipediaのメニューの話だっての、そこの頭ガチガチのガキ。
言葉尻だけつかまえて、得意げに飛躍してんのはお前だ。
strict信者にロクなヤツいねえってのはホントだな。
実装こそ重要。机上の空論をこねくり回しても無駄なんだよ。

件のメニューは国ではなく言語を表しているのだが、ゆと教世代の地理の教科書には
English という国が載っているのかね?

悪いけど言語と国の区別も付かずに振り上げてしまった拳を下ろせなくなってるようにしか
見えんのだが。

>>456
誰が拳を振り上げてると？
"その国の言語"と書けと？
そんなくだらねーことをいちいち訂正しろと？
言葉尻をどうこう言ってるだけじゃねえか。大馬鹿。

日本語すら満足に理解出来ない奴に
（Strictを語ることは）難しい

「lang="その国"」 → 「lang="その国の言語"」 って言いたかったのか?
苦しいのうｗｗｗ　てか国：言語 が 1：1 になるという脳でないと出ない発想だな。
表現能力が低いと社会生活も苦労するだろ。

>>458
へえ、一言一句正確無比な正しい日本語で書かなきゃいけないんだ？
句読点も打てないくせに、他人にだけ厳しいんだな。
2chでそんな事言い出したらキリないぞ、国語の先生。

あのさ、436はlang="hoge"とすれば任意の国の言語が（フォントがあれば）表示される、って言ってんだろ？
「化けてる国をクリックする」ってどういうこと？どうしてそれが「lang="その国"になる」の？

なにこのスレ

>>459
>>458といい、一言も省略しちゃいけないらしいな。
＞てか国：言語 が 1：1 になるという脳
何を言ってるんだかな。とても理解出来ないわ。

これが火病って奴か…初めて見たぜ

>>464
まだまだ夜は長い。これからだぜ

＞その理屈だと、wikipediaでは化けてる国 (の言語) をクリックすればいい (=正しく表示される) って事になるな。
＞(その言語のトップページに移動して) lang="その国 (の言語)" になるんだから。

と言いたかったんだと思ワレ

うん？
サイドメニューにあるときにlang属性の指定が適切でないから表示されないのではないか、
試しにローカルにダウンロードして適切にlang属性を付与したら表示された、と436は言ってるんだろ？
それがなんでまた「その言語のトップページに移動すればいい」ってことになるの？
何の問題解決にもなっていないどころか何の問題提起にもなっていないように見えるんだが。

>>466
あんたすげぇよｗ
右クリックすると化けてる部分の lang 指定変えられるブラウザでも使ってるのかと思った。

テルグ君の人気に嫉妬

最早Strictとは何の関係も無いな

>>457 は、そもそも国と言語の違いが分かってない。「その国の言語」という
言い方でも正しくない。例えば、スイスではドイツ語とフランス語が同等に
話されている。国と言語が対応すると思うのが間違い。

あと、>>432 はlangの値によって化けたり化けなかったりするという話を
していたのであって、フォントがない場合は最初から話題に挙がってない。

>>471
いや>>463で「とても理解出来ない」って言ってるからｗ

>>461
lang=""は関係ない、fontが入ってるかどうかだって、その前の方でもう出てる話なんだ。
それをスルーして>>436は、lang="その国の言語"とすれば表示されると
繰り返し言ってる。
>>438では、そうじゃない、メニューの"その国の言語"をクリックすればlang="その国の言語"になるのに、
表示はされない、と繰り返したわけ。

　>427 言語任意なところはlang指定を無効にしときたいんだけどlang=""でおけ？
　>429 言語任意ってなんじゃらほい
　>430 たとえばWikipediaの言語メニューみたいな感じよ。ウチとかうまく表示されない環境があるんよ
　>439,440 lang="und"、もしくはXHTML1.1ならlang=""でいいよ
ってあたりが話の本筋だな。

>>473
436あたりを読んでると「フォントが入っていても文字化けするケースがある」と言及していて、
その要因としてlang="hoge"が怪しいと436は睨んでいる、と書いてあるように見えるのだが、
そこらへんの言及を全部すっ飛ばして「クリックせよ → 解決 → PDFにしなさい」って438に書いてある。
三行目の状況は438の場合、で、436は状況が違うんでしょ？（少なくともその可能性がある）
エスパー頼みで奇妙なやり取り始めないでくれよ。無駄に40レスも消費してるじゃないか。

443、447、449で終了でしょ。流れ読めてないのは451ｗｗｗ

>>451の逆切れっぷりにわろたｗ
まあこんな程度で感情をあらわにする程度の人なんだな。
自分の説明と言うか日本語がおかしいだけなのに他人の読解力のせいにしてるし。

どうみても>438は

>そうじゃない、メニューの"その国の言語"をクリックすればlang="その国の言語"になるのに、
>表示はされない、と繰り返したわけ。

とは読めない

438のPCでの話なんてだれも訊いてないよな。

質問には全く答えず、他人の言葉尻を貶すのが楽しいだけの底辺集団だな。
あの程度で逆切れ扱いじゃあ、世の中逆切れだらけだっつーの。
せいぜい隔離スレで屁理屈をこねまわして悦にいってりゃいいのさ。

Wikipedia は実害の例として引き合いに出しただけかと思うが。
結局質問は一部言語混在をどう定義するかに始終してるわけだし。

>>432 は、Wikipediaの「キムチ」の項の lang="ko" 部分のハングルは
表示されるが、lang="ja" 部分のハングルは表示されないと言ってるから、
フォントがないせいではなく、「IEがバカ」というのが結論。

　　　　　　　　　　　　　　　　　　　　亠ｧ厂|　　　　　　　　`':,;..:..:.';.　　　　 ;'..:..:.,:'
　　　　　　　　　　　　 　 　 　 　 　 ‐个 兀　　　　　　　　　　`:;:.::.':.,　　　,':.::.:,:'
｀.:`.:''''..:.‐ :.:-:.:...,,,,　__　　　､‐-、　　　　　　　 __ 　　,.‐z_,-､　　 '':;;:::':, ,...;'::..:,;'　　,,.:':
..:..:...:..:..:...:...:...:.:..:...:...:..:.｀＿,,ﾉ　└¬､'''.:.:‐:..,,ヾ､__)∠,ｨｸ ／,、　　　';:''..:.:..:..:.:..:.'':;'':.:.,;.
.:..:...:..:..:...:...:...:.:..:...:...:..:.ヾ､_　　　＜^'".:..:..:.:..: ＜`ヾ´~_　 _~´ 〉'''':.::.;':.::...:.:..:..:..:...:.:.';'　,,
..:..:...:..:..:...:...: ,,;,;,;,,;:..:..:.:.:..: /　/＼　`ヽ､..:..:.:..:..:_ブ∧ ‐　‐　/.:.:..:,;,::';..:..:..:.:..:..:..:...:.:.:''´:.:
:..:.:..:..,.:-〜' , ､ｍ_）°.:.:.'ｰ-'..:..:..:`ｰ--',,;,;::.:.:ヽ､_i (_,/しﾍﾍ_） ´　　'::;.:.::.:..:..:..:..:.:..,;'｀ ''
,;,,;,;/　　＜て_;:､｡.:° ‐　''''　"　´　´　　　　　　　　　　　　　　　,;:''.:.:,:'' :;,._.:,;.,､:.'':.,,_
　 /　r'７ｧｯｰヘ､_) ﾟ　　　　　　　　　　　　　　　　　　　　　　,,:''.:.:,:'' , -〜''ヽ‐-‐､.:.:.''
-く 　ﾚ'/〈　°　　　｡　　　　　,ﾍVﾌヽ、　　　　　　　　　 ,,:''.:.:.:,:'' 　(_,ヘ､　　　　　⌒
　　Ｖ巛〈 ヽ 　, 〜''ヽ　　　　/ e　ヽノ＼ﾍ. 　　　　　,,:.''..::.:,:''　。 　 　　と_刀Tゥｰ
＿/　ヾ ヽ､ Ｙ ｧ个〜'。ﾟ　 ,少ｰ- 代ヽ､ ヾゝ 　 ,,.: '':.:/ヽ､'　｡ ﾟ (⌒⌒ｰ-く ﾉﾉ,!j
　{.　　 ＼　Ｙ巛〈 　　 　 　） l�f�gレﾞく　　＼''.:.::.:.:.:/ /　入 ﾟ ｡ `〜<ヾヾ､,｀⌒ 〜
_, ヘ、　　ヾ{　ヾﾄ､　 　 　 'ヾゝｬ�gﾒ�l�`　　 ヾﾖ　/〃／ _,,＞　　　 〉〉ﾉ ｀厂丁｀
　　　＼　　＼　　ヽ、　　　　｀ゞへ�m�f�i�_　 ゞ�dｆ‐ '' ´　　　　　 ///／　　ﾉ
─〜 ⌒ヽ､　 ＼　　 ヽ、　　　 ´｀'‐ニ世三r＜�k´　　　　　　 ＿,,ノ,〆　　 ／
　　　 ＿_,, へ、　＼　　 ` ー- ､＿＿　　　　　　＿,, --‐‐ ''´　　　　　_ - ´　 ／
￣￣　　　　　 ＼　　` ｰ- ､ ＿　　　　￣￣￣　　　　　　　＿, -〜＜ -一 ブ
　　　　　　　　　　ヽ､、　　　　　 ￣｀ ー─----── ´￣　　　　＿ -一 ´

>>480
質問の本質も見極められず「ご高説に反論」とかファビョってるお前にはわからんだろうな。
隔離スレですら馬鹿にされるなんて大層なご身分だこと。

>そうじゃない、メニューの"その国の言語"をクリックすればlang="その国の言語"になるのに、
>表示はされない、と繰り返したわけ。

さっきは反論したと言ってみたり、今度は繰り返したと言ってみたり…

「繰り返し反論した」とまとめるに一票

結論：IEのみで確認するな

>>483
全くだなｗ

結局、何で国に突っ込まれてるのか全く気付いてなかったわけか。
まぁ気付いてるなら 「その国の言語」 なんて表現は使わないか。

ところでこのスレにまだ結構人がいたことに驚いたよ
俺みたいな残党? しか残ってないのかと思った

>>488
針がないから釣りじゃなくて単なる燃料投下

>>490
みんな自分から振るようなネタがもうない
でもスレは定期的にチェキ
これ

上の方のやりとりが意味不明です。

Don't Think. Feel.

このスレ的に、aのhref属性の値にjavascriptスキームのURIを置くのってどうよ？
直接HTMLとは関係ないけど。

RFCかIANAに登録されたら認めてやってもいい

じゃあ about:blank もダメか。歴史はそこそこあるのに。

ttp://d.hatena.ne.jp/keyword/%a5%ed%a1%bc%a5%de%bf%f4%bb%fa
ttp://ja.wikipedia.org/wiki/%E3%83%AD%E3%83%BC%E3%83%9E%E6%95%B0%E5%AD%97
ttp://www.aboutworks.com/shokodei/diary/doc/roman-UTF8/

ローマ数字を書くときは「I」とか「II」なんかでいいのかな。
span要素とlang（もしくはxml:lang）属性でマークした方がいいかと思って
どこの言語なのか調べたものの、結局わからなかった。

文字と言語は別物だよ
ローマ数字も英語の文脈に出てくれば英語だし
日本語の文脈に出てくれば日本語
日本語のローマ字表記はローマの言葉ではなく日本語なのと同じ

>>498
ISO 15924の"Latn"を使えばいいのでは
ja-Latnとか

>499-500
どうもありがとうございます。
ja-Latnなどと書くのは独自拡張というか、主観がけっこう影響しそうなので、
今回はとくにマークしないことにしようと思います。

ttp://209.85.175.104/search?q=cache:suika.fam.cx/~wakaba/-temp/wiki/wiki%3F%25CD%25D1%25BB%25FA%25B7%25CF%25BB%25A5+Latn+%22ISO+15924
ttp://d.hatena.ne.jp/momdo/20071204
後で見つけた情報もついでに置いておきます。

変な質問でしたらすみません。
fieldsetの中に複数のformを入れるのは
マークアップとして適切でしょうか？
普通は(？)formの中にfieldsetを入れて、
その中にフォームの部品を入れるっぽいですけど……

ちなみにlintには怒られませんでした。

ってここ質問スレじゃなかったですね。
吊ってきます……

質問がだめなんて書いてないが。

fieldsetはフォームをグループ化するんじゃなく
フォーム内の関連ある入力項目やラベルをグループ化するものだから
fieldsetが複数のformを内包するのはアカン
逆にformがfieldsetを複数持つのはおｋ

グループ化というか構造化だな

一番の謎は、

* fieldset要素がブロック要素の一覧に含まれている。
　……つまり、form要素に関係ないfieldset要素をbody要素直下に置ける。
* fieldset要素の内容モデルにブロック要素が含まれている。
　……つまり、form要素内にないfieldset要素なら直下にform要素が置ける。

というDTDだ。なお、form要素の例外規則により、form > fieldset > form という
構造は禁止されている。fieldset要素がform要素限定の要素なら、

* fieldset要素をブロック要素に含めず。
* form要素の内容モデルにfieldset要素を含める。

という書き方も出来たのに、なぜこうなっているのか。ここに問題を解く鍵は
ないだろうか。

fieldset
　dl
　　dt
　　　label
　　dt
　　　input
みたく構造化するためにブロック要素なのでは

間違った、二つ目のdtはddです
他にtableでthにlabel、tdにinputという書き方もあるか

>>508
いや、fieldsetの内容の話じゃない。

例えば、dd要素はdl要素の中にしか置けないがdd要素の中にはブロック要素が
置ける。それと同じように、「fieldset要素はform要素の中にしか置けないが
fieldset要素の中にはブロック要素が置ける」というDTDにすることも出来たはず。
それなのにそうなってないのはなぜかという話。

つまり、なぜfieldset要素は一般のブロック要素であって、form要素と関係ない
場所にでも置けるような仕様になっているのかということ。

divとどうちがうんだ？

なぜdiv

どこにでも書ける構造化要素ってことだと、divとの違いが曖昧になるって
言いたいんだろ。まあ、一番の違いはlegend要素の存在なのかな。

まあ、JavaScript だけで動作する Webツールとかだと、form要素はいらないからなー。
action 属性に何を入れるんだ、という。
でも input とかの入力要素は使いたくて構造化したい場合には fieldset は使いたいから、
form の中以外にでも置けるのはいいんだけど。

ただ fieldset の中に form は気持ち悪いな。 「form control group」 って書いてるし。

DTDってどこまで厳密に議論されてるのかね
>>510のようにするつもりが「あ、ゴメン忘れてたｗ、
みたいなことはあるのだろうか…

Referer みたいに RFC でもスペルミスや間違い単語が仕様になってしまった
ものをよく見かける。

>>514
そもそも、input要素をform要素の外に置くのはStrictか、という話になりそうだな。

例えば、インラインでスクロールバーを出したいが為に <textarea readonly> を
使っているページがある。しかし本来ならCSSの overflow: scroll; でやるべきところだ。
また、Javascriptの実行結果を出力する場所として input要素を使っているページが
ある。これも本来はDOMを使うべきところだろう。

どうも、form要素の外にinputなどを置くというのは、その手のStrictでないものを
思い浮かべてしまう。もちろん、出力欄としてではなく、本当に入力欄として使い、
それをJavascriptで処理するという場合もあるだろうが、Javascriptのみでしか
動かないとすると、アクセシビリティ的にどうなんだろう。

明らかにそのページはJavascriptによるアクションがある訳だから、その場合、
formのaction属性に代替ページを指定しておくべきような気もするんだが。

strict-erなら当然だわな

そもそも<head><body>はstrictか？

日本語でおｋ

<fieldset>
<img ...>
<legend>図 2.1<legend>
</fieldset>
みたいな使い方ができたら便利なんだが、仕様書のタイトルが
「17.10 Adding structure to forms: the FIELDSET and LEGEND elements」
なのだから、フォーム以外で使うのは変だよなあ。

「<br>は改行だからなるべく使わないようにしましょう」みたいなStricterサイトをよく見かけるが、
<br>ってのはbreakの略で、「コーヒーブレイク」みたいに「小休止」って意味だろ。

つまりパラグラフを分けるほどではないが、ちょっと小休止を挟みたいということで、
それがたまたまほとんどのブラウザで「改行させる」という動作として実装されているわけだ。

「<h1>タグは文字の大きさを変える効果があります」というのは最近では噴飯物として扱われるが、
「<br>は改行するタグです」や「<br>は物理要素なので使わないようにしましょう」という主張が
未だにまかり通るのが不思議で仕方が無い。
しかもXHTML2.0では<br>が<l></l>要素なんていう、正真正銘の物理要素になっちゃったし。

> <br>ってのはbreakの略で、「コーヒーブレイク」みたいに「小休止」って意味だろ。
コーヒー噴いたｗ

息の長いスレに一つは存在してそうなコピペ系文章だな。

釣りは釣り堀で

breakはbreakでも改行を意味するんだがなあ…
改行という見た目を表すbrは物理要素だ
XHTML2のl要素はlineのlであって意味的な行を表す論理要素だ
改行として扱うかはユーザーの閲覧環境次第

小休止ﾜﾛﾀ

甘酒吹いたｗ
この1〜2スレしかのぞいてない新参だから
分からないんだけど、これコピペか何か？

>>576
横からすまんが、br要素が物理要素だとする根拠はどこにあるんだ？
仕様書には「行」としか書かれてなくて、それが論理的な行か物理的な行かは
書かれてないというか、どちらとも解釈できるように思えるんだが。

で、br要素は「現在行の終了」であって、「改行」つまり新しい行の始まりとは
別だとも読める。もちろん「現在の行が終われば自動的に次の行が始まるのか」
という命題の答えは仕様書からは読めない。だからこれもどちらとも解釈できるが、
短絡的に改行とイコールだと考えてしまうのは危険だと思う。

すまん、>>576 じゃなくて、>>526 だ。

まあなんというか、世間的に物理要素と認識されているけど
brを使いたいからその建前が欲しいという訳だ。
XHTML2で用意された建前がl要素だと。

>>529
短絡も何も「現在行の終了」と「（続きがあるなら）新しい行の開始」は不可分。
そして普通それは、パラグラフ（p）の終わり毎に行を改めることで表現される。

パラグラフ途中での強制的な改行（forced line break）を指示するのがbr。
「サブパラグラフが終了したので改行」せよと解釈できなくもないが
仕様では「行を改めよ」という見た目しか指してない。だから物理要素とした。

もっとも、XHTML 1.1に準拠すればbrはspanとともに
PresentationalではなくStructualなモジュールとされてるけど。

>>531
brを論理要素としたとしても空要素ではどこからどこまでが
副段落なので改行したのかが曖昧だが
l要素だとそれをきちんと構造化できるから単なる建前ではない。

そもそもパラグラフの始まりを
新規に行を始めることで表わす
必然性も無いしな。¶記号で区
切る流儀もあるわけだし。

何つーか、その辺をなあなあにして
videoやらarticleやら、web 2.0的風潮に媚び媚びな
追加ばかりのHTML5が気にくわないのは俺だけか

だってブラウザベンダーに都合のいいのがhtml5だし。

まあそうだよな
しかし(X)HTML5とか書いてるやつはバカかと思う

>>532
その「不可分」と考えるのが短絡的だという話をしてるんだけど。
例えば、段落が終了した（</p>）からって勝手に次の段落が始まったり（<p>）は
しないでしょ？　それを考えれば、行が終了したって勝手に次の行は始まらなくて、
次の行の内容（文字等）が現れた時点で初めて次の行が始まるという解釈も出来る訳。

「行を改めよ」じゃなくて「行を終われ」。次の行が始まるかどうかは規定されて
ない。そしてその「行」とは見た目の行なのか、セマンティックな行なのかも規定
されてないという話。

あと、パラグラフは「／」で区切るスタイルもあるから、パラグラフと見た目の行の
切れ目とは何の関係もない。セマンティックな行なら切れ目になるだろうけどね。

空要素も関係ないよ。「<p><l>A</l><l>B</l></p>」と「<p>A<br/>B</p>」を
完全に等価とする仕様も可能だから、空要素かどうかではなく、要素の意味が
どういう仕様になっているかどうかだ。

今気付いたんだけど BR ってブレードランナーの略じゃね？

パラグラフを斜線とか¶で区切って書くのはいいが
HTML/CSS的にはp::before {content::"¶";}とかの
領分だと思うんだが…なんのためのpだよ
<pre>
¶〜〜〜
¶〜〜〜
¶〜〜〜
</pre>
みたいに書くのか？

>>539
ソースと表示がごっちゃになってるよ。
HTMLのソースに斜線などで区切って書くという話じゃなくて、スタイルとして
区切って表示するという話だよ。そういうスタイルもあり得るからパラグラフと
見た目の（物理的な）行は関係ないという話。

br要素が見た目の（物理的な）行の終わりを表すのだとすれば br { display: none }
などで表示した場合にはbr要素の意味を失うことになるが、セマンティックな
（論理的な）行の終わりを表すのだとすれば、いかなるスタイルにしようとその
意味は失われない。そこが物理要素か論理要素かの分かれ目だろ。

brが物理/表象的か論理/構造的かは準拠するDTDによる。

具体的にどのDTDがどうなんだ？

My DTDは論理的

XHTML1.1でPresentation ModuleではなくText Moduleに
入ってることを考えれば、<br>要素は論理要素と考える方が
自然なような気もする。つまり見た目の行ではなく、論理的な
行を終わらせるんだと思う。

<br>要素と<l>要素の関係は、見出しによる暗黙セクションと
<section>要素の関係に似てると思う。いずれも後者の方が
要素が囲まれてるのでCSSやDOMで利用しやすい。でも、
セマンティックな意味としては前者でも変わらないと思う。

<hr> と同じ感じかな

あれ、brが物理だ(と認識されていた)からlを導入したとかじゃなかったっけ。

モジュールの分類を考えると確かに論理要素なんだよな。
でも、現実にbrがどういう所で使われているかと言えば、
ほとんどの場合、物理表現のために使われている。
これが物理要素だと認識される原因なのかもな。

strict的に白黒つけるのは難しいと思う。

物理要素か論理要素かよりも、
行頭を明示せずに行末だけ<br>で示す
って言うのがstrict的じゃない気がする。

まあ確かに、それを言えば
終端に<p>を置くことで段落の区切りを示す、
なんて設計もありえたわけだからな。

それを言うとseparator要素も同じ話だよな。先頭を示さず区切りだけ示している。

でも、要素構造(DOMツリー)なんてしょせん意味構造(セマンティック)を導く手段
なんだから、strictな意味構造を導けるんだったら、要素構造がstrict的でないという
のも変な話かもしれん。

もともと単なる見た目の改行のためにbrが作られたことを
考えれば、物理的なものと見なすのが自然でしょう。
最初からbrが論理的だなんて理屈をこねる必要がないし。

後になって構造と表現の分離の考えが出てきて、
既存の見た目オンリーな要素をどうにかしましょう的な流れになった。
革新派は要素の置き換え・改変を主張し、保守派は
既存の要素に論理を後付けして使うことを主張した。
まあ、そんなもん。

＞もともと単なる見た目の改行のためにbrが作られたことを考えれば
それが証明できないからもめてるのかと思ったよ。

>>553
HTML2とかの時代の背景や進化の歴史を考えれば自明じゃない？
それとも、統計を取ってないから証明できないとかいういつもの話？

まあ、今でも一応l要素 vs br要素みたいなのがくすぶっているようだから、
上に出たような理屈でbrが(名前は変わるかもしれんが)
XHTML2とかに導入される可能性もないわけでもないな。
仕様って政治的に決まるからな。

>>554
歴史や背景を論じても仕方ないだろ。

例えば、HR要素の仕様はこう変化している。

HTML2.0
　… HR要素はセクションの区切りである。典型的には横線として表示される。
HTML3.2
　… HR要素は話題の変化を示すために使える。音声UAではポーズなどで表現する。
HTML4.0
　… HR要素は視覚的なUAで横線を表示する。
XHTML1.1
　… hr要素はPresentation Moduleに含まれる。

これを見ると、HR要素はHTML3.2までは論理要素で、HTML4.0からは物理要素に
なっている。

この例からも分かるように、「HTMLの進化を考えれば、元々は物理的なもの
として誕生し、のちに論理的な意味が後付け」なんていう進化論はおかしい。

結局物理だろうが論理だろうがこじつけで後からどうとでもいえるからな。
歴史や背景を論じてもしょうがないとは思うが、
その歴史や背景を見るのが一番正解に近いとも思うわ。

仕様書には"The BR element forcibly breaks (ends) the current line of text."
とあるのだから、br要素は改行によって見た目を整形する物理要素と捉えるのが
自然だと思う。

このスレッド90%はループでできています。

このスレのシリーズも随分続いたもんだな。
来年も生きつづけるのか。

さておき、良いお年を。

>>558
おまえ、流れ読んでないだろ。
その line という語が論理行か物理行か分からんという話をしてたのに。

仕様書に書いてないことを読み取る修行？

明けましておめでとう。

>>562
むしろオレオレ仕様書を作る修行

>>561
各々のケースを考えてみりゃいいでしょ。
見た目を整形する「物理行」としてのlineは万人に共通して受け入れられることが予想できるが、
「論理行」て何？まずコンセンサスを得るのに一苦労要る、っていうのは問題だと思う。

>>564
それは文書を論理的に考えてないからだろ。

「段落」なんていう論理概念は、形式段落なのか意味段落なのか、まずコンセンサスを
得るのに一苦労要るが、前後が改行されたブロックの区切りであるという見た目での
説明なら万人に共通して理解され得る。……とか言ってるのと同レベルだぞ。

ひどい詭弁を見た。

>>566
阿呆

>>565
まず「論理行」が何を指してるのか具体的に明示してから話を進めろよ。
意味段落も形式段落も国語で教えるから一般的だが（義務教育をおさめてりゃな）、
論理行も物理行も一部のギークにしか通用しない言葉の可能性がある。

ところで後半の説明は酷い意図的なミスリーディングだな。
564では「物理行 = line は理解が得やすく受け入れ易い、論理行てのはコンセンサスが得られていない」
と書いてるのに対して、あたかも「物理行は見た目で分かりやすいから理解されやすい」と書いてるように曲げてる。
問題はそこじゃないでしょ。いかにも見てくれ至上主義の側の人みたいなイメージ植え付けんのやめろよ。

dl, dt, dd　を使ってる人を見ると分かってるなぁと思う。

はあ？

物理行とは例えば表示幅に収まらなくて折り返して出来る行などスタイルによって
変化する見た目の行のこと。論理行とは例えば詩やコンピュータ言語の行など、
見た目を除いても存在するセマンティックな行のこと。

スタイルやメディアによって変化するかは一つのポイントだが、これは
物理要素と論理要素の違いが分かっていれば分かるはず。それをコンセンサスが
ないと言えば、物理要素と論理要素の違いもコンセンサスがないことになる。

論理行についてはXHTML2.0の仕様には書かれているが、HTML4.01の仕様書には
書かれてないのでどっちを指すのかは不明だ。

<p>ようするに<br><br><br><br><br>
こんなのがOKだと<br><br><br><br><br>
いいたいんだな（字余り）<br><br><br><br><br><br><p>

あ<br>
い<br>
う<br>
え<br>
お

>>572
それは誰に対して言ってるんだ？

br

ちんこ

そもそもbrの意図として必要な状況も多いしいいじゃんとも思うけどな。
英語に比べて単語が改行をまたいでも意味を理解しやすい言語とはいえ、
適切な文節で改行がなされると意味も取りやすい訳だし。
そんなのは論理マークアップじゃないとか言い出すやつがいそうだけど、
英語が単語の途中で改行されないのと同じと考えると良い。

あと話しが変わるがストリクタのサイトに良くあるひたすらだだ流し込んだような文章は、
横幅も異様に広いし正直読みづらくてかなわん。
（brというかコンテナに相当するdivとかを絶対使わない辺りが原因だろうけど）
見た目を気にしないにも程があるって程にな。
ストリクト精神もいいけど、そんなのは見た目やユーザビリティも出来た上で
初めて評価してもいいと思える。

ストリクタってどっからどこまで？

>>577
CSSの考察が足りないんだと思うよ彼らは

その発言はあらぬ方向に議論を向かわせそうだなｗ

その読みにくいサイトをここで晒しくだしあ)*(

>>571の言う論理行って、コンピュータでテキストを扱うときにしか有効
でない気がする。一般に「行」って言えば、CSSで言うところの行ボックス
みたいな見た目のものを指す。ただのテキストに論理行は存在するのかな？

>>577
brで適切な文節で改行というが、UAの表示幅が狭い場合は、そのような
改行が入った方が逆に読みにくくなる。例えば20文字目でbrを入れた文書を、
表示幅が19文字しかないUAで見ると、1文字だけあふれて読みにくいなど。
従ってあらゆるメディアを考えた場合、HTMLでは見た目のための改行は入れる
べきでない。

また、brやdivなどが一切なくても、段落のwidth、max-width、min-width等を
CSSで適切に設定すれば、行が長過ぎて読みづらいというような問題は起こらない。
つまり、そのサイトはCSSが問題なのであってHTMLが問題なのではない。

>>582
小説の会話文とかはどうだ。段落の途中であっても改行され、それは表示幅に
合わせるなど見た目のために発生した行ではなく、会話文という論理的な意味に
よって発生した行だから、論理行だと思う。こういう所に使うbrなら論理的な
改行ではないかな。

小説の作法はまだ論議の余地があると思う。文章の中に「」が突拍子もなく現れたり、
「」と「」の合間を改行しない方法も許される。そして決して稀なものというわけでもない。
紙媒体が主だったから調整のために行われた改行が一般的になって長く用いられたわけであって、
論理的な意味としての行とか改行かといえばちょっとパンチが弱い気がする。

CSSじゃなくてデザインだな。
デザインを取るとstrict的には不必要なマークアップを必要とする場合があるから、
デザイン的な制限も多い。
それ故にCSSだけでどうこうなる問題じゃないってことも多い。
まあ殆どがそれ以前のデザインセンスの問題なんだろうけどｗ
どっちにしてもダメってことだーね。

>>577
ウィンドウサイズを縮めて読みやすい幅にすればいいじゃん

「<br>は改行だからなるべく使わないようにしましょう」みたいなStricterサイトをよく見かけるが、
<br>ってのはbreakの略で、「コーヒーブレイク」みたいに「小休止」って意味だろ。

つまりパラグラフを分けるほどではないが、ちょっと小休止を挟みたいということで、
それがたまたまほとんどのブラウザで「改行させる」という動作として実装されているわけだ。

「<h1>タグは文字の大きさを変える効果があります」というのは最近では噴飯物として扱われるが、
「<br>は改行するタグです」や「<br>は物理要素なので使わないようにしましょう」という主張が
未だにまかり通るのが不思議で仕方が無い。
しかもXHTML2.0では<br>が<l></l>要素なんていう、正真正銘の物理要素になっちゃったし。

line break だろ。

>>522

改行の話なら、少し前にソフ板のMozilla Firefox Part75スレでやってたな

そのときに叩かれてたサイト
http://beau.g-com.ne.jp/mon-extension-memo.html

始まりはこんな感じ

61 ：名無しさん＠お腹いっぱい。：2007/12/16(日) 17:25:45 ID:bfRKxvFc0
何年も言いたかったことだがついに言う！Mozilla Firefox Thunderbird の拡張あれこれの中の人は改行しらんのか？！

>>589
あぁ、過去の話だったのね。すまん。

確かに見難いよな。
改行がないとどこ読んでたかわからなくなってくる。
。とかの位置でなんとかわかるけど、
もっと目に見えてわかる文字とそれ以外の部分の形がないと、見づらくてしょうがない。

>>590
fixed width なのに見辛いのはどうなのって感じだな

この人は句読点が少なすぎるな

もうHTMLとか関係なくね？

ネットの文章ってケータイ小説みたいなのが理想だからな
紙の技術書の感覚で書くと異様に詰まった感じを受けてしまう

br みたいな空要素より l みたいな中に文字が入ってる要素の方がスタイルシートやスクリプトで飾り付ける時は便利だよな。
ってスタイルシートを前提にしている時点で Stricter じゃありませんかそうですか。

Strictorな

>>598
http://oshiete1.goo.ne.jp/qa241288.html

>599
何が言いたいんだ？

br要素で文の区切りをマークアップするより、文を何らかの要素でマークアップする方が合理的だと思う。
あと、文書に改行の概念ってあるの？改行って視覚が無ければ存在し得ない物だと思うのだけど

sage忘れたorz

「改行＝(意味)段落の切り替え」じゃね？

ｗｗ
http://yanagi.myminicity.com/com
http://yanagi.myminicity.com/ind
http://yanagi.myminicity.com/tra
http://yanagi.myminicity.com/sec
http://yanagi.myminicity.com/

文章のリズムとかって意図や意味もあるよな。
ひとつの文章をブロックでぶった切ってマークアップする訳にもいかないし、
行をspanとかでdisplay:block;指定してもCSSがOFF時に意味不明になる。

詩とかがいろいろとマークアップしづらいのもそういう事の積み重ねにある訳だし。

>>601
むしろ段落の概念の方が文書にとっては後付け

(短歌、俳句含めた)詩の方が小説や論文より前からある概念だし
そして詩は行中の空白区切り、改行、空行で構成される

それを「、」「。」そして段落に「移植」する事は可能ではあるけど

おまいら日本語と、せいぜい英語の言語・文法体系しか頭にないのに
こんなところで文章の意味付けなんて論議しても意味無いんじゃないか。
それとも日本語用の HTML 解釈とかしてんのか。

>>606
後付けかどうかが問題ではないでしょ

段落があろうがなかろうが改行という概念は文書から外せないという事だろ

>>607
単にオレオレ仕様を熱く語ってるだけだから、放置すればいい。

話についていけないからって拗ねなくてもいいのに。

p と br と div 位しかない HTML の意味付けで悩むより
自作の XML ボキャブラリ作った方がいいんじゃね？　とは時々思う。

そんなことより「早くapplication/xhtml+xmlにしろよ、うんこMS」と思う。

あれ？対応を間違えて消してしまった。
まあよっぽどの阿保じゃない限り、推測で意味はわかるだろうしいいけど。

MSXMLのXML解釈は多少はマシになったのか？
IE7とか使ってないからさっぱりわからん。

XHTMLで思い出したけど、XHML 1.1のDTD(フラット版)
http://www.w3.org/TR/xhtml11-flat.dtd
の末尾に
<html><head><title>title</title></head><body><p>text</p></body></html>
って謎のHTML片があるんだけど何なのこれ。

http://www.w3.org/TR/xhtmi11/DTD/xhtml11-flat.dtd

だった。

また間違えてるorz

http://www.w3.org/TR/xhtml11/DTD/xhtml11-flat.dtd

です、ｽﾏｿ

改行は必要だろう。

br みたいな改行指定より
l みたいな行をマークするやり方の方がよかったとは思うけど、
今更言っても遅いよなとも思う。

>>605
詩はpreで

そんなことは基本としてわかった上で、
普通の文章もリズムが必要とされる場合があるって事だろ。
詩はそれが特に必要とされてるってだけだ。

Bunshou Markup Language

(X)HTMLって論文みたいなのを意識してるわけだから、
詩なんかは拡張語彙つくってそれでマーク付けしたほうがいいよなあ

>そんなことは基本としてわかった上で、

わかった上でも何も、それ以上のことは何も必要ないというのに。

難しい日本語だなあ

詩的

改行に意味がある文章は整形済みテキストってことなんだからPREでいいだろ。

実際、メールとか掲示板の書き込みとかだと、
１段落全部１行でかかずに適当なとこで改行して書いてるわけじゃん。
上までのレスみたってほとんどのひとが適当な句読点で区切ってる。
なぜかって、読みやすくするようにだろ？

なのに、ことHTMLを書く段になると、とたんに改行しちゃだめってなるのが、ちょっとわからない。
読みづらくなるのは CSS のせいとかいうし。 なんでそこだけ CSS 想定してんだよ。

例えば、このスレでもどっかの掲示板でも日記でもいいんだけど、
「フォームに入力された改行は BR にしないで、連続した改行ごとに P 段落に区切る」
って処理をした方が、好みの仕様になるってことなのかな？

一般人にとっては、すごい読みにくくて邪魔くさいと感じる仕様だと思うんだけど。

>>627
俺が2chのCSSをいじれるなら適切な文字幅を指定して改行不要な文章を書くこともできる。
しかも2chはある程度の文字数で改行しないと投稿できないシステムになっている。
上記二件をクリアさせてくれるなら、俺は句読点ごとに改行はしない。できないから次善の策で改行する。

>「フォームに入力された改行は BR にしないで、連続した改行ごとに P 段落に区切る」
>って処理をした方が、好みの仕様になるってことなのかな？

消極的に賛同

>一般人にとっては、すごい読みにくくて邪魔くさいと感じる仕様だと思うんだけど。

一般人て誰？どこの人？誰が調査したの？

句読点で改行を入れているブログとか多いよね。ウェブ独特の文章作法なのか
もしれないが、そういう文章作法を認めないと言うと、HTMLの仕様に合わせて
人間が書いた文章を改変するという、本末転倒なことになりかねない。

>>626
横スクロールバーが出ちゃうと詩とか困るやん
PREなんてAAとプログラムのソースくらいにしか使えないよ

>>630
なんで詩だと困るの？むしろ折り返しがおこらなくていいんじゃない？

>>629
前段の文章と後段の文章がつながらんと思う。
むしろ「ウェブ独特の文章作法」がHTMLの仕様に合わせて改変したものだと考えられるので、
そういう文章作法を認めないということは一見筋の通ったことのように見えるが。

>>631
横スクロールバーを1行毎に左右しながら読むのが快適だとでも？

>>628
> 一般人
現在どこの会社の運営するブログも掲示板もそういう仕様になってないのが、
一般人にとってはそういう需要がないっていう証拠にならないか？

ぐだぐだに改行されまくった詩なんて掲載されたくない罠

>>634
サービスの仕様が需要だけに基づいて決定されると本気で思ってんの？
お前の言う仕様とそうでない仕様が二つ並べられて、使い勝手を比べた上で決定したわけじゃないでしょ。
ただ単に制作者側がやりやすい仕様で構成されて、誰もが読みにくいも読みにくくないも念頭にないだけ、
つう可能性があると思うんだが。どのみち確証にはならんな。

つーかスレちがい

一行ごと改行を入れて書き込むという作法は、Web BBS誕生以前から、
パソコン通信、ネットニュース、電子メール等で存在した作法だ。
これらはtext/plainのメディアだったから自分で改行を入れて整形
しなきゃならなかった。Web BBSは、それらパソコン通信等をWeb上で
再現しただけのシステムだ。

例えば、今、ここにリストを書きたいとする。
・項目
・項目
などと、「・」を使って書いたりするだろう。ul要素のようなもので
構造化したりはしない。これは、現在のBBSもまだtext/plainメディア
であることの証拠だ。HTMLはたまたまそのtext/plainを転送するために
被せてるに過ぎない。実際に転送したいのはtext/plainなのだ。

結論。Web BBSは結局text/plainメディアなのであって、HTMLの仕様に
合わせたものではない。その作法をもってHTMLを云々するのはおかしい。

そりゃそうだろ。
htmlのマークアップは、もともと存在する文書に付随するものでしかないし。

だが、text/plainの文化だったとしても、
そこに文書があるならそれにはマークアップが存在するってのもhtmlの文化。
ベースになる文書自体が改行されてるんだから、
htmlの仕様でbrはあまり使うべきじゃなかろうが改行は必要ってだけ。

brに改行しないcss指定が出来るだけでいいとおもうんだがねぇ。

ユーザCSSでbr{display:none;}

そりゃリストとかはそうだろうけど、
こと段落においては、別に文章は改行しなくても通じるし、
ウィンドウのサイズに合わせて自動で折り返されるし、
メールだったらある文字数で勝手に折り返されるわけじゃん。

じゃあなんで改行してるのさ、って話で。
「そのほうが読みやすいから」 って理由じゃないの？

HTMLにするときだけ、なんでわざわざ頑なに 「読みにくく」 しなきゃいけないのかと。

・・・まあ俺も余計な改行はいらないとは思う派なんだが、
形式段落に使うくらいは認めてもらわないと困る。

>>641
HTMLは読みやすくするためのものではない。
意味があるべきところに「タグ」を使って要素を位置づけ、意味をUAに読めるようにするもの。
改行に意味があるのなら意味づけをする。ないのならしない。
「読みやすさ」が不可欠なものなら（改行されないと意味が変わってしまうのなら）改行する。
改行してもしなくても本質的な意味に違いがないのなら、HTMLで意味づけすることはしない。

つか別にこんな偏屈スレで自分の用法が認められようがどうだっていいじゃん。
禁止されてるわけでも実用に弊害があるわけでもないんだからどんどん改行すれ。

>>615
パーサにかけてみたらエラーになった。何なんだろうね。
onsgmls:xhtml11-flat.dtd:4615:0:E: 宣言サブセット内では文字 "]" は禁止されています

>>639
おいおい。text/plainはベースになる文書そのものじゃないだろ。

text/plainは、構造や見た目を改行や空白などで表すことが出来、
いや「表すしかなく」か、
HTML/CSSでは、構造をHTML、見た目をCSSで表すことが出来る。

だから、text/plainからちゃんとしたHTML/CSSに変換しようと思ったら、
HTMLでli要素を指定する際には項目頭に付いた「・」の文字を取り除いたり、
CSSで行幅を指定する際には見た目のための改行を取り除いたりという
作業が必要になる。インデントの空白等も同様。

これらは本来の元の文書にはなかったものであり、text/plainだからこそ
追加されたものだからだ。

・とかも含めての文書だろ。
マークアップする際に取捨選択がされてるだけだ。

そもそも読むための文書に見た目が大きく影響しないわけが無い訳で、
文書が存在する時点で読みやすさ等の見た目も考慮されてるもの。
機械的に出力したものではなく、人間が頭で考えて読ませるために書いたものは、
それだけで必然的に読みやすさ等の配慮がなされていると言っていい。

仮にインデントや・が無かった場合、その部分の文章に与えられた意味自体が伝わらず、
本来の元の文書にあったはずの意味や意図が変質してしまう事からも、
本来の文書に無かったものが追加されたとは言いがたい。

話は戻るが、読みやすさへの配慮が切り離せないのは、文書や文章を用意する目的等により、
どの程度の量なのか、あるいはどの程度のスペースに入るような量なのか等、
文書や文章と見た目は密接な関係にある為。

上記みたいな制約に囚われず書き出された文書や文書はかなり特殊と言っていい。
それこそコンテンツの量に制限が無く、文章を記述した時点でマークアップをしていくかのような状況や、
見た目を徹底的に排除した論理マークアップであることを前提や目的とした文書や文章で無い限りね。

>マークアップする際に取捨選択がされてるだけだ。

違うね。卵とひよこの話になるが、紙媒体（などの単方向メディア）での提示を前提とされているために
本質的なデータに「リストである」などの情報を付加するための「・」などが追加されたわけだ。
紙媒体（あるいはtext/plainなど）のための暗黙のマークアップがされているとも言える。

>そもそも読むための文書に見た目が大きく影響しないわけが無い訳で、
>文書が存在する時点で読みやすさ等の見た目も考慮されてるもの。

HTMLは必ずしも人間が「読む」ためのものではない。UAが解釈することが本質。
二行目は何が言いたいのかよくわからんが。紙媒体での幅の取り方が文書のデータ本質に影響するの？

>仮にインデントや・が無かった場合、その部分の文章に与えられた意味自体が伝わらず、

HTMLにはリストアップのための要素が存在する。意味はそれで伝えられる。
視覚的に認識させるかどうかはUAの仕事であり、その方法は必ず「・」を使用するとは定められていない。

>読みやすさへの配慮が切り離せないのは、文書や文章を用意する目的等により、
>どの程度の量なのか、あるいはどの程度のスペースに入るような量なのか等、
>文書や文章と見た目は密接な関係にある為。

それはCSSの仕事。HTMLに余分なものを付加する必要性は全くない。

どこのにわかストリクタだ？

日本語の勉強からした方がいいよ。

CSSの仕事じゃなくて、
本来の文書には無かったものをtext/plainにした際に追加されたものかどうかって話だし。

だってここの人達は考える基準がHTMLだもん

>>647
だから本来HTMLが担うべき「構造」がCSSで指定する「見た目」でしか表現できていないから問題なんだろ
DocBookとかだとHTMLよりはもう少しマシだけど
いずれにしろ「文書」に期待される構造表現にHTMLという規格は全然とどいていない
それが問題

だからHTML「にも」ある構造表現を問題にしても意味がないよ

>>647
なんでストリクタのくせにCSSを前提としてるの？

>>650
それは要するに、「一行の文字数」などは見た目ではなく構造だと言いたい訳か？

じゃあ、音声ブラウザや、小さな携帯端末などでは、その文書は表現出来ない
ということか？

ここまで俺のコメント　-->

>>652
それは「AAは音声ブラウザで表現できない」というのと同じ問題だね
本来的な表示ができない端末では代替表現
(次に表示される行が本来は右に並べられるものである事を示す記号をつけるなど)
でどうにかするしかないでしょう

実際、詩や小説だと一行あたりの文字数というのは重大な問題だし
(ユーザーエージェントでの表示が短すぎる場合はもとより長すぎる場合も)

縦読みとかも構造だなｗ
特殊？そんなのはごく普通にありえる表現方法のひとつで、
縦読みだからpreで・・・とかはナンセンスでしかない。
縦読みという構造を付与したらマークアップがpreでしかなされないのは、
文書本来のマークアップを捻じ曲げていると言うことになるし。

途端にどうでもいい話題になったな

途端?

負け惜しみだからそっとしておいてあげなされ

>>654
同じ小説が、新聞連載とハードカバーと文庫本で1行文字数が違うことは
どう考えてるんだ。1行文字数は内容ではなく見た目だからこそ、
スタイルによって変わるんだろ。

詩も1行文字数が問題なんじゃない。どこで切れるかが問題なんだろ。

だから構造的な切れ目の位置はbr要素で指定し、1行文字数などの
見た目はCSSなどで指定し、行を整形するだけの（見た目だけの）改行は
除くんだろ。

>>651
ストリクタがCSSを扱うことを否定する根拠がどこにあるのかさっぱりわからん。
なんでストリクトスレに居る癖に見た目の整形をHTMLで行おうとするの？

>>654
「本来的な表示」って何？表示に意味が託されるということ？
それこそpre要素でテキストの配置に意味があることを情報として付与するべき。

>(次に表示される行が本来は右に並べられるものである事を示す記号をつけるなど)

愚策。その記号を付けた文書を「本来的な表示」が出来るUAで閲覧したら、
不要なところへ不要な記号が無意味に取り付けられてるということになるね。

>実際、詩や小説だと一行あたりの文字数というのは重大な問題だし

どこの国で？

>>655
>特殊？そんなのはごく普通にありえる表現方法のひとつで、
>縦読みだからpreで・・・とかはナンセンスでしかない。

現在日本での文字の読み方は左→右か、上→下のどちらかひとつがメイン。
両方を同時に成立させようとする用法は、万葉集だかの短歌以降から2chまでほとんど陽の目を見ていない。
縦読みは縦に文字を辿れることに意味があるので、pre要素によるマークアップは妥当と考えられる。
妥当でない根拠が「ナンセンスでしかない」では話にならない。具体的にポイント示してね。

>縦読みという構造を付与したらマークアップがpreでしかなされないのは、
>文書本来のマークアップを捻じ曲げていると言うことになるし。

ならない。

>>659
概ね同意

brは物理要素

CSS で昔 Netscape にあった wbr だっけ？
表示幅が十分なら折り返さない、表示幅が足りないならこの要素がある位置で改行する
って指定が出来たらいいのに。
nobr は white-space で出来るけど。

>>661
縦読みが仕込まれてたらたったそれだけの理由でpreになるの？

>>664
（例えば縦に辿る）必要があるのなら必要に応じたマークアップをする。ないならしない。
どんな理由があってpre要素では適切でないと判断するの？

たったｗｗｗｗｗそれだけｗｗｗｗｗ

縦読みは一種の詩だろ

>>663
span { float: left }

よりにもよって span

>>665
縦って気づかれないようにこっそり仕込むものだから、
普通は正しくマークアップなんか出来ないんだけど。
気づけなきゃマークアップ出来ないっておかしくない？
意味を読み取れようが読み取れなかろうが、文章はそこにあって意味を持ち、
そこには既にマークアップが存在しているのに、
preでマークアップしそこねると文章本来の意味が損なわれるのはおかしい。
preが適切ではないってのはそういう意味。

だから縦読みの文章の構造をマークアップするとしたら、
普段の文章もpreでないと対応できない。
改行をbrとしてマークアップし取り除かないなら、何の違和感も修正も無く対応できるけど。

だめだこいつ。

>縦って気づかれないようにこっそり仕込むものだから、
>普通は正しくマークアップなんか出来ないんだけど。
>気づけなきゃマークアップ出来ないっておかしくない？

したくないんならすんなボケが。

>意味を読み取れようが読み取れなかろうが、文章はそこにあって意味を持ち、
>そこには既にマークアップが存在しているのに、

してねえ。text/plainおよび紙媒体などのWeb以前のメディアにマークアップなど存在せん。
意味を持つならXMLで何がしかのマークアップは可能（なはず）。
明示化・定義できない意味なんぞ存在しないのと同義。暗黙の了解でも方言でも好きにしろ。

>preでマークアップしそこねると文章本来の意味が損なわれるのはおかしい。
>preが適切ではないってのはそういう意味。

あのな、文章が持つ本意を要素でマークアップするわけじゃない。
文章の持つ役割を要素でマークアップするんだ。
<s>僕</s>は林檎を<v>食べる</v>。
文章の意味は文章が持つ。文章を構成する要素の役割はマークアップ言語が明示化する。
これでもってpre要素以外に適切なものがある、って言い張るんならさっさと明示しろボケ。
マークアップしたくないんならするな。何でこのスレ来てんだよアホが。
改行したいんなら改行しろ。マークアップ言語の意味合いも理解しないで何がストリクタだ。

質問ですけど、タブ幅を表示する要素ってありますか？
プログラミング系のホームページ作ってるから、タブ幅出力出来たほうが便利なんだよね。
（だから、「スタイルシートで何文字分インデント」とかじゃなくてちゃんと\tが出力されるようにしたい）
preだと右端で自動改行されないから見づらくなってしまうんです。
>>663のwbrみたいなのがあればいいけど。

preの話題が出てたので質問しました。

>>670
もしテキスト執筆者とマークアップする人が別人の場合は、縦読みがあるのなら、
縦読みありと伝えておくべきだ。それを伝えずに正しいマークアップを期待する
方がおかしい。気づかなきゃマークアップ出来ないのは当然のことなんだよ。

気づかなくて、つまり機械的にマークアップ出来るのなら、text/plainのままで
自動処理できることになるので、マークアップ言語なんて要らなくなる。

改行だけの問題じゃないぞ。text/plainなら、見出しをスペースでセンタリング
してあるようなのもある。このスペースを取り除くのかといった部分も同じ問題だ。

>>671
前の方で語られてたtext/plainのマークアップとは、マークアップ言語のような
かっちりしたもののことじゃなくて、上述のセンタリングのスペースやリストの
「・」記号のようなもののことだよ。

>>672
明らかにスレ違い
CSS2.1 white-space: pre-wrap あとは調べろ

>>671
お前がダメだろ。
文書があったらそこにはマークアップが存在する、それがHTMLなのに。
Web以前の媒体だろうがなんだろうがそれは同じ。

「マークアップ」 というか段落とかリストとかの構造だな。
それを機械にもわかるように指定するのがマークアップ。
文章があったらそこに構造が存在する、ってーんならわかる。

で、改行も構造にはいるかどうかって話で。

「入る場合もある」、「絶対入らない」 というひとはいるが、
「全て入る」 ってひとはこのスレにいないと思うけど。

>>676
「構造」とは違うぞ。センタリングのためのスペースとかは構造じゃないだろ。
「マークアップ」という言い方がまずいなら「構造や見た目を表すために
加えられた文字」だな。改行もそういうものだという話。

>>675
Web以前の媒体でHTMLを適用した具体例を聞かせてくれよ。
例えば紙媒体なんかでマークアップに伴い構造を理解するUAの具体例を挙げてくれよ。
HTMLとMLを混同すんな。text/htmlとtext/plainとXMLと紙と、違いをよくよく考えろ。

>>676
概ね同意。
マークアップは構造の明示化（UAに対する）、構造は要素の寄せ集め。
文章に各要素が存在（点在）するのは明らかなことで、マークアップはそれの整理にも繋がる。
もちろん要素は要素だけで意味を成さないのは>>671で書いたアホみたいな例の通り。

>>677
狙ったように不可解な例ばっか…「センタリングのためのスペース」って何？
センタリングすることに意味があるのか？センタリングされることが不可欠で意味が変わる？
頼むから具体例を出してくれ。あと改行をpre要素でマークアップしてはいけない具体的な理由も。

>>678
日本語でおｋ

>>675=677=679 m9(^Д^)ﾌﾟｷﾞｬｰ

>>678

|　　　　　　　　　　　　　　　　HTMLとは
|
|　HTMLとは、なんたらかんたら…

というtext/plain文書があった時、この「HTMLとは」という見出しの前にある
スペースのことだよ。このスペースは文書本来のものではなく、一種の「マーク
アップ」（本来の文書に対して付け加えられた文字）だと言ったんだ。まあ、
確かに「マークアップ」という言い方は誤解を招く言い方だったな。

人が何人かいるのでまとめると、

(A)text/plainには本来の文書に対して付け加えられた文字（マークアップ）がある
(B)text/plainこそ本来の文書（マークアップ前）

(1)構造的な意味のある改行はbrで、見た目の改行はCSSで記述すべき
(2)構造的な意味のある改行はpreで、見た目の改行はCSSで記述すべき
(3)改行はすべてbrで記述すべき（すべて意味がある）

と少なくともこれだけの派閥があると思う。俺(>>673=>>677)は(A)(1)で、
>>670 は(A)(3)で、お前(>>671=>>678)は(B)(2)なのかな？
>>676 もお前か。>>675 は >>670 の可能性はあるが不明。4人目かも知れん。

で、preがまずいのは、詩ならいいが、「構造的な改行を含む段落」までが
pではなくpreになってしまうからじゃないのか。

あ、読み返したら >>676 はお前とは別人のようだな。てことは少なくとも
4人いるな。

今日も今日とてオレオレ談義

>>675は俺。
こんな事言っても証明できないが他には書き込んでないぞ。

何言ってんだ、675は俺だぞ

いやいや俺が本当の675だし。
偽の2人は消えろよ。

My name is 675. Get out of here.

誰がハゲやねん！

>>688
よう、禿げ。

お前らアホか
さっきまで何の話をしてたか思い出せるか？
結論を聞かせてくれ

br に論理的な意味はあるのか、あるとすればどんな場合に使うべきなのか、pre ではだめなのか、
ってとこか？　結論は知らん。

ここで訊くのが適切かどうか分からんけどすまん、ちょっと質問。

http://mynotes.jp/blog/2007/12/order-of-attributes

見てて思ったんだが、属性を書く順番って好みの問題で要素の意味(解釈？)には影響しないんだよな？
XML Infomation Set 的にも順番は保存されないし。

pre厨の誕生である。

div厨より質悪そうだなｗ

Predocのことかーーーー
ttp://www.netfort.gr.jp/~kiyoka/predoc/index_ja.html

text/html でマーク付けに悩むより
text/plain で自由に書いた方がシアワセだよきっと。

会話文での改行も詩の「間」もタブも
ついでに行頭のインデントも見出しのセンタリングも自由自在だぜ？

その悩むのが楽しいんですう＞＜

>>695
こんなのあるのか。何も悩まなくていいな。
タイトルくらいつけられたほうがいいんじゃないかと思ったが、プレーン
テキストなんだしそんなの不要かな。

ネタだろうと思ってみてみたら何気に便利そうでﾜﾗﾀｗ
一応文字コードぐらいは指定してほしいけど。

>>692
SGMLでもXMLでも属性の順序は自由で意味は変わらない。

【HTML互換】Predocを語れっ！【軽量】
http://pc11.2ch.net/test/read.cgi/hp/1168170940/

>>692
スキーマによっては属性の順番は限定される。
XHTMLにおいては自由。

>>695
軽量なのはいいが、
文書型宣言もtitleも書いてないHTMLなんてStrict以前にValidでも無いじゃないか。

いや、HTMLじゃないし・・・

【HTML互換】という部分が間違ってるな。

<html>や<head>や<body>などのタグは元々省略可能だから、あとはせめて
<title>だけでもあれば、下位互換になっただろうに。

「制限したHTMLです」
「WebサイトにPredocを置けば、そのままWebページになります」
「HTMLのサブセット」

むしろXMLにした方がいいんじゃないかと思う。
XML宣言さえ書いておけば、後はtitle無くても
「XHTMLっぽい独自のXMLなんです」
って言えるし。

そこで登場Predoc2.0

>>705
HTML4ではpreの中にimgを入れられないから、HTML4のサブセットにはできない。
W3Cの定めたSGML応用のHTML4のサブセットではないことは明らかだけど、何の
サブセットなのかはよくわからないね。

>>708
むしろXPredoc

昨日出たHTML 5のWDだとbr要素は
> br elements must only be used for line breaks that are actually part
of the content, as in poems or addresses.
http://www.w3.org/TR/html5/#the-br
ってなってるね。

<p><a ...>34 comments.</a><br>
<a ...>Add a comment.<a></p>
みたいなのは駄目で、
<p><a ...>34 comments.</a></p>
<p><a ...>Add a comment.<a></p>
しろだってさ。これはきついなー。

いや、
> br elements must not be used for separating thematic groups in a paragraph.
> The following examples are non-conforming, as they abuse the br element:
って書いてるだけジャン

それに >>710 の例だったらいままでだって br 使わないで UL-LI とか使ってるだろ

アドレスでの改行って内容の内なのか、という点で疑問があるけど
ポエムの方は妥当だよね

もうポエムには DocBook でも使えよと。

てめーが使え。
俺はpre使うから。

みんなでPreDoc使おう。

いや

詩の評論では、詩の改行はスラッシュに変換して1連を1行に表記する。
だから詩の改行を「整形済み」とするのは違う気がする。
詩人の先生曰く、改行部分で「ポエジー（叙情）」を表現するんだと。
俺は強制改行＝意味の「区切り（単なる切れ目）」でいいと思うが。

>>717
それじゃ、リストの項目を区切り文字込みで一行にすることがあるなら
リストに見えるように整形したテキストでも整形済みじゃなくなっちゃう。

「スラッシュに変換」という整形をすでにしているテキストは、
結局整形済みテキストだよね。整形の仕方が一通りでなくとも、
整形したテキストとして意味づけしたいなら、preでいいよ。

あと、強制改行は強制改行という意味づけ。意味の区切れ目とか
まではいかないと思う。（それは詩文化とか形式段落文化とかの、
HTMLの上に乗っかるルールの方で与えられる意味だろうから。）

リズムっていうマークアップでなら納得できるけど。

>>718
普通に改行で発表された作品をスラッシュ区切りに変えることが認められる。
つまり詩の作品は、区切りさえ伝達すれば改行で表示しようがスラッシュ区切りで表示しようがレンダリ
ング任せで構わないということ。
表示をレンダリング任せで構わないpreって明らかに変だろ。

oreore1.0

俳句をHTMLで表現せよ

>>720
認められる、ていうのは、公認というより代替案がないから黙認、て感じだな。
XHTML1.1をtext/htmlで送るのと似たようなもんだ。続けていいわけじゃない。

紙面には限りがあるからな。

>>720
> つまり詩の作品は、区切りさえ伝達すれば改行で表示しようがスラッシュ区切りで表示しようがレンダリ
> ング任せで構わないということ。
何らかのマークアップで区切り形式をレンダリング任せにするならな。

preの場合はどちらかの形式に整形したテキストをpreの内容とすることになる。

SGMLの機能文字について質問なのですが、RE(記録終了)とRS(記録開始)って
何なのでしょうか？「記録」というのがよくわかりません。

>>726
http://suika.fam.cx/~wakaba/-temp/wiki/wiki?%B5%AD%CF%BF

下記の様なdl要素の使用方法は、定義リストとして相応しくないでしょうか？

<dl class="navigator">

　　<dt><a href="">XHTML</a></dt>
　　　　<dd><a href="">HTMLについて</a></dd>
　　　　<dd><a href="">XMLについて</a></dd>

　　<dt><a href="">CSS</a></dt>
　　　　<dd><a href="">CSSについて</a></dd>
　　　　<dd><a href="">XSLについて</a></dd>

</dl>

下記のようなってのは、
1つのdtに対してddが複数定義されてるってことを指してるの？
だとしたら別に問題ないよ。

>>729
質問の仕方がまずかったですね…すみません。
定義ではないリンクとしての使用について、です。

厳密に言えば、本来なら
<dl>
　　<dt>HTML</dt>
　　<dd>HyperText Markup Languageの略</dd>
　　<dd>Webページを記述するためのマークアップ言語</dd>
</dl>
の様に、「定義」の為のリストだと思うのですが、
>>728の様に「定義」ではないリンク(メニュー)用のリストとして使用するのは如何かと…。

俺なら ul の入れ子を使う。

定義へのアンカーだから問題ないように感じるけど。

んあ？

ul の入れ子って匿名ブロックの問題があるよな。
インラインとブロックを同一要素の子要素として共存させるべきでないって話。

<ul>
<li>Aについて</li>
<li>Bについて <!-- ←ここが匿名ブロック -->
<ul>
<li>B1について</li>
<li>B2について</li>
</ul></li>
</ul>

このようにAとBが同レベルの問題で、Bだけはさらにサブレベルの問題がある
場合に特に困るんだが、「Bについて」という項目名の匿名ブロックを避けようと
これをブロック要素にすると、「Aについて」とアンバランスになる。

これが目次だった場合とかを考えると、p要素にするわけにもいかない。
どう解決する？

>>734
「Bについて」を入れ子リストの見出しにするのか
リスト項目のひとつとするのかをはっきりしない
734の迷いがそのまま反映された形だな。

見出しと見なすなら「Aについて」と意味が違うんだから
ブロック要素としてもとくにアンバランスではない。

「Bについて」を「Aについて」と同様のリスト項目だと見なすなら、
「Bについて」とBの入れ子リストを別のリスト項目にして
両者の関連づけについては諦めるしかない。

>>734-735
目次だと考えると、すべては見出しなんだが、そこには本文は一切ないという構造、
というか、見出しだけを集めたリンク集か。

階層の深さは章ごとに異なるだろうし、孫レベルもあるだろうし、divしか思い
浮かばないが、そうすると全部のliをdivにしなきゃならなくなるから気持ち悪い。
分からん。

>>736
あるテキストがある文章に対する見出しだからって、
リスト項目になったらその文書構造上は見出しじゃないよ。
「見出し」って言葉に引き摺られて混同しちゃだめよ。

例えば、本文中にニュースの見出しテキストが出てくる場合でも、
それはHTMLでいう見出しではない、ってのと同じ話。

何で匿名ブロックを避けたがる人多いんだろうねえ。
単に CSS 関連の用語なだけで、
HTML の構造うんぬんには関係ないのに、っていつも思うんだけど。
TABLE の TBODY みたいに暗黙的に構造が省略されてる、ってわけでもないしさ。

見出しなら最初から dl 使うべきだし
単にBの li の中が「ul を含む文章」というだけなら

<ul>
<li><p>Aについて</p></li>
<li><p>Bについて</p> <!-- ←ここが匿名ブロック -->
<ul>
<li>B1について</li>
<li>B2について</li>
</ul></li>
</ul>

とでもすればいいだけだから、大した問題とも思えないが

匿名ブロックってあくまでCSSの問題でしょ。
HTML自体の問題ではなくて、それをCSSで扱うときの問題。

ていうかHTMLの仕様書自体が>>734みたいな使い方してるし、
HTMLとしての構造はこれが正解でいいんじゃね。

DOM的には>734の「Aについて」も「Bについて」も同じテキストノードか。

>>739
> 見出しなら最初から dl 使うべきだし
用語と定義みたいな対となる項目のリストとしてじゃなくて、
見出し付きリストがリストの項目になってるだけならdlにはならんでしょ。

HTML5の草案では匿名ブロックを禁止してるぞ。
インライン要素とブロック要素が兄弟要素になってはならない。
これは、匿名ブロックを嫌う人がそれだけ多かった結果じゃないのかな。

>>742
もう禁止してない

だってHTML5は何でもありの闇鍋だもの

>>739
目次の見出し名って段落なのか？

W3C的にはpにそこまで厳密な意味は持たせてない。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.4
http://www.w3.org/TR/html5/#the-p
あたりの用例見る限りは。

もちろん、「いや、厳密に文法的な意味での段落としてしか使わないぜ」というのも
ありだろうけど、そこまでHTMLが意味づけしてくれる訳じゃないってこったな。

>>734
ブロックレベル要素とインライン要素(やテキスト)の混在と
匿名ブロックボックスはCSS上では関連があるけど
HTML上では関連がないので切り分けた方が混乱がなくていいと思う

自分は入れ子リストあたりの混在は仕方ないと割り切って無視するけど
気になるならliの内容をブロックレベル要素だけにする、と決めて、
dlの適用範囲を広げるようにpの適用範囲を広げて
いままでliの子だったテキストを全部pの子にしていいんじゃないか

あるものの解説をするページを作っていて、
「青い色の星マーク」と「黄色の星マーク」を、
「★」の記号を使って表示しようと思っています。
どちらも、ページ内で何度か利用するので、
span 要素などで囲んで class 名を設けようと思うのですが、
span.blue や span.yellow 等の class 命は、
あまり適切でないような気がしています…。

このように、フォントの色のみが問題な場合、
どんなクラス名を付けるのが適切だと思いますか？
皆さんの個人的な考えでも結構ですので
教えて下さい。

<ul>
  <li>
    <dl>
      <dt>list1</dt>
      <dd>
        <ul>
          <li>list1-1</li>
          <li>list1-2</li>
        </ul>
      </dd>
    </dl>
  </li>
  <li>
    <dl>
      <dt>list2</dt>
      <dd>
        <ul>
          <li>list2-1</li>
          <li>list2-2</li>
        </ul>
      </dd>
    </dl>
  </li>
</ul>

これでおｋ
・・・なわけないか
リストにもキャプション付くようになるのはhtml5だっけ

⊂ミ⊃＾ω＾ ）⊃　ｱｳｱｳ!!

>>748
そういう視覚依存になる文書自体を見直す

>>749
>リストにもキャプション付くようになるのはhtml5だっけ
XHTML 2だな

>>748
色分けする明確な基準があれば、その基準でクラス名をつける
基準がなければ（例えば交互に青黄青黄とする）、クラス名にblueやyellowってつければいいんじゃないの？

>>748
title属性で「青い色の星マーク」と「黄色の星マーク」を指定して
それをセレクタにすれば？

>>748
たとえば、金賞と銀賞を示す★記号があるときに、
goldstarとかsilverstarとかやっちゃいかんということはない。
フォントの色を示すんじゃなくて、記号の名前や意味を示すつもりならOK。

ほんとうに「フォントの色の違いは、表示上の区別のためだけ」って話なら、
HTMLで表示色に基づいた考え方をしてクラス名付けするのは不適切。
この場合は、star1とかstar2とか、または★の記号の意味に基づいて
（たとえば本文のmainstarと補足文のnotestarとか）名前を与えることになる。

「○○○」というサイトにある、
★（青い星のマーク）のリンクは企業のサイト、
★（黄色い星のマーク）のリンクは個人のサイト、
へのリンク集です。

というような文章を書こうと考えています。

>>752
★の記号自体は同じ記号なので、
色の違いを明確に伝えるべきか、とは思っています。

>>753
そんな指定の仕方が出来るんですか？
調べてみます…。

レスしてから>>754さんのレスに気が付きました；；

「記号の意味」を示すつもりならOKですか。
確かに、2つの記号には一応別々の意味があるので、
bluestar と yellowstar でも悪くはないですね。
これでやってみたいと思います。
ありがとうございました。

>>755-756
青い星、黄色い星の使用方法が本当にそれなら、
bluestar、yellowstarは違うような気がする。

>>754が例に出した、金賞・銀賞ってのは
世間一般的に「金が優勝、銀が準優勝」というような
何かに対する優秀度を示していることが共通認識になってる。
だから、金色・銀色自体に意味があるとみなして、
goldstar、silverstarというclassもありだと考えられる。

が、「企業が青、個人が黄色」ってのは、
755が勝手に決めた色のルールで、実際には意味がない。
それなら、完全に良い例か分からないけど、

<a href=

>>757続き

途中で送信した、ｽﾏｿ。

<a href="xxx" class="link-corporate">企業</a>
<a href="zzz" class="link-personal">個人</a>

みたいな感じにして、★はCSSで表示させたらどうだろう。
（背景画像を使うなどの手法で）

>>757-758
あ、そうか、リンク先の内容の意味を考えないといけなかったわけですね。
そうすると確かに、単に bluestar yellowstar ではよくないですね；
参考になりました。ありがとうございます。

「<br>は改行だからなるべく使わないようにしましょう」みたいなStricterサイトをよく見かけるが、
<br>ってのはbreakの略で、「コーヒーブレイク」みたいに「小休止」って意味だろ。

つまりパラグラフを分けるほどではないが、ちょっと小休止を挟みたいということで、
それがたまたまほとんどのブラウザで「改行させる」という動作として実装されているわけだ。

「<h1>タグは文字の大きさを変える効果があります」というのは最近では噴飯物として扱われるが、
「<br>は改行するタグです」や「<br>は物理要素なので使わないようにしましょう」という主張が
未だにまかり通るのが不思議で仕方が無い。
しかもXHTML2.0では<br>が<l></l>要素なんていう、正真正銘の物理要素になっちゃったし。

>>522
>>587
>>760

>>760
仕様書嫁
"line" breakって書いてあるだろ

またループしてるのかよ。
lineとは物理行を指すのか論理行を指すのかわからないって話が
ちょっと前にあっただろ。

タグに使われている英語が、何の略かを記述したサイトはありませんか？

掲示板の投稿者、発言、そのスレッドのタイトルとかありますよね、
そういうのってどうマークアップするのが適切なんでしょうか。
スレッドのタイトルも<h>とかでマークアップすべきとか？

>>764
ttp://www.w3.org/TR/html4/

そんな誰が作ったのかわからないような、うさんくさい所じゃなくて、
信用のおける所は何かないですかね？
わけあって正確な情報が必要なのです。

microsoftのmsdnサイトでHTMLリファレンスを発見したのですが
ここも何の略かはっきり書いてないですね・・・
引き続き情報をよろしくお願いいたします。

ﾜﾛﾀｗ
どっかのコピペか？ｗ

>>766
ありがとうございます。参考になります。

掲示板の投稿者、発言、そのスレッドのタイトルとかありますよね、
そういうのってどうマークアップするのが適切なんでしょうか。
スレッドのタイトルも<h>とかでマークアップすべきとか？

ﾜﾛﾀｗ
どっかのコピペか？ｗ

>>770
うん。そのほうがいいんじゃない？

すいません、マジですw
発言は引用<blockquote>でタイトルはページに則ったランクの<h>だと思うんですが
w3c的に投稿者とかはどう処理していけばいいんですかね。
普通そういうのは上記項目一まとめに段落<p>で囲って終了なんですかね。
futaba.phpと言う画像掲示板適切にマークアップし直したいだけなんですが。

>>773
うーん、発言者はpでいいんじゃないか？

とりあえずレス本文がblockquoteってのはないだろ。

スレッドのタイトルはh、dlで全レスをリスト、
dtにはレス本文以外の全部の情報、ddにレス本文、
あたりがいいんじゃね。
会話文dlと同様の感じで。

BBSみたいなのっていつもマークアップに悩むよな
いっそ新しい語彙作っちゃった方が早いんじゃないかと思うくらい

全部、リストでやっちまったり

あーなるほど、リストとかもいけそうですよね。
もうほんと毎回悩みますわ、専用タグとか出してもらいたい・・・

タグとかいう即物的なカテゴライズで考えるのをやめて、
文書が要素群だと考えるようになるといくらか楽にストリクれるかも知れない。

HTMLは専用じゃなくて汎用だから、「簡素なBBS向け」
「フォーラム系BBS向け」とか、「ポータルサイト向け」とか
「ブログのサイドバー向け」とかいう作りはしてないんだよね。

だから、自分の書こうとしてる文書の意味を的確に表せるというよりは、
その文書に限った意味をHTMLの規定する汎用的な意味へと変換して
利用者に供する、って感じだと思った方がいいと思う。

HTML なんてレイアウト用のスクラッチと割り切ってるからどうでもええがな。
静的なデータは XML、動的なデータは DB で持ってるし。

俺にとっちゃお前のデータの扱いの方がはるかにどうでもいい

>>781
なんでこのスレにいるの？

このスレ見て定義リストで割り振ってみたけど
リスト内に<h>タグは駄目らしいですね。
さてどうしたものか。

なんでリスト内に

上で言って頂いてるのって
<dl>
<dt>投稿者の各項目（タイトルは<h>で囲む）</dt>
<dd>レス送信者の各項目（タイトルは上記より1ランク低い<h>で囲む）</dd>
</dl>
と言う感じではなかったですかね？
私自身ブロック要素とインライン要素考えずにやってミスしてたんですが。

>>786
釣りじゃなかったら、寒気がするほどひどいぞ。
お前はいったい何を読んだんだ……

・・・・すいましぇん。
投稿1つあたりの内容を定義ファイルで分けると言うことでしたかね？・・・
久々にhtmlいじったもので・・・・・・

<hn>スレタイ</hn>
<dl>
        <dt>投稿者名　投稿日時　等</dt>
        <dd>こんにちは。ここはひどいインターネッツですね。</dd>
        <dt>投稿者名　投稿日時　等</dt>
        <dd>同意しすぎて禿げ上がったぜ。</dd>
        <dt>投稿者名　投稿日時　等</dt>
        <dd>定義ファイル……？</dd>
</dl>

あ、ありがたやー。
<dl>タグってこういう書き込み方も出来たんですね。
スレタイのみに<h>適用させてレスのサブタイトルは無しの方向で
やると楽なのか。

futaba.phpだと、2chと違って投稿者名の他にレスタイトルもあるわけね。
で、dtは内容にinlineなものしかとれないからhをつっこめなくて難儀したと。

<hn>スレタイ</hn>
<dl>
<dt>レスタイトル</dt>
<dd>投稿者名　投稿日時　等</dd>
<dd>こんにちは。ここはひどいインターネッツですね。</dd>
<dt>レスタイトル</dt>
<dd>投稿者名　投稿日時　等</dd>
<dd>同意しすぎて禿げ上がったぜ。</dd>
<dt>レスタイトル</dt>
<dd>投稿者名　投稿日時　等</dd>
<dd>定義ファイル……？</dd>
</dl>

あたりかな。適宜class属性を割り振るとして。

私のつたない日本語で理解するよう努力して頂いてほんとすいません、
上記をテンプレートとしてfutaba.phpを改装したいと思います。

>>791
こういう感じなら、
投稿者名とかを更に<ul><li>でマークアップしてもいいかもね。
まあちょっとクドくなるけど。

レス毎にdlを分けるのもアリだと思う。

<body>タグにではなく<html>タグにクラスなりIDを振ってCSSで装飾するのってあり？

手持ちのブラウザでは問題なく動作したけど、あまりやっている人いないよね。
推奨された使い方じゃないのかな。

しかし>>789とか>>791って意味的にマズくないか

わーしょしんしゃがいっぱぁーい
よろしくねぼくもしょしんしゃだよv

「DL要素の応用として、例えば対話のマーク付けがある。 DT要素が話者を示し、DD要素が話の内容を示す、というものである。」
ttp://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/lists.html#h-10.3

とあるから、dtで投稿者名などをあらわして、ddで発言内容を表しても別に大丈夫なんじゃね？

大丈夫かじゃなく、最適かどうかを語るのがストリクタじゃないのか？

796が「意味的にマズいなら最適じゃない」と言って
798が「とりあえず意味的にマズくはない」と言って、
799が、最適じゃない他の理由を挙げてくれるのを待ってるところ。

他人に頼るなカス

仕様書にそういう使い方もありと書いてあるだからありなんでしょ

勉強になるなぁこのスレ

>>795
もっと人のソース見たほうがいい。bodyのclassとか超使われてる
body.archiveとかbody.entryみたく、ページのタイプを分けるとか。

あとIE6みたくドメインでユーザーCSSを切りかえれないようなUA向けに
body.www-google-co-jp dl dt { ... } みたいなで、
そのドメインでだけ効くセレクタ使えるにしとくるのも一時期流行った

JSでブラウザ識別し、bodyにフラグとしてclass付与して
　　body.firefox ... {}
　　body.ie6 ... {...}
みたいに振り分けてるの見たことある
まあ俺はCSSのハックですますけど

> <body>タグにではなく<html>タグに

>>>>795
XHTML1.0 Strict DTDによれば
htmlが持てる属性はlang, xml:lang, id, xmlnsのみ、
すなわちclassはダメ。他のDTDは知らん

すまん、dirもok。まあclassがダメというのは変わらんが

>>804
>もっと人のソース見たほうがいい。bodyのclassとか超使われてる
もっと人のレスをよく見たほうがいい。

>>795
htmlにclass属性のある勧告仕様は今までなかったはず (HTML 5 WDだとあるけど)
id属性もXHTML 1.1とかXHTML 1.0 SE以前にはなかったから
あんまり普及してないんだと思う

あ、XHTML 2 WDにもhtmlにclassあるな

CSSシグネチャ云々でbodyにID振りつつ
htmlにもスタイル指定してる奴は全員htmlにID振った方がいい
文書の作成者がUAの機能不備を補う必要はないけど

<p>　<![CDATA[　<>&　]]>　</p>

これを表示させると、
IE7
<>&　]]>

Opera9
<>&

Firefox2

↑何も表示されない

となるのですが、一体正しいのはどれでしょう？
それとも、どのように表示されるかは、決まっていないのでしょうか？
すくなくとも、IE7だけはありえないと思うのですが。

Opera9じゃね？

>>812
Operaが正しい。
FxにCDATAセクションを認識させたかったらapplication/xhtml+xml渡さないと。

ローカルなファイルに対して確かめたのですが、
もし、content typeがpplication/xhtml+xmlだったら、
FirefoxもOperaと同じ挙動をするということですね。

しかし、ローカルなファイルに対しては、MIMEも何もあったもんじゃないから、
HTMLか、あるいはXHTMLかは、ファイル内容で判断してほしいものですが。

しかし、IE7だけは理解できない。
CDATA事態は認識していそうなんだけど

単にIEがマーク区間に対応してないんじゃね？
Firefox 2は、HTMLではマーク区間を無視、
XMLではマーク区間を適切に処理、って感じなんだろう。

ローカルでは拡張子xhtmlかxhtmならFirefoxはXMLとして
解釈してくれたよ。…ってここまで書いて気づいたけど、
こんな実装の話はスレ違いだね。

ちょっと気になったことがあるんだけど、
もしXMLベースのスクリプト言語があって、それをXHTML文書に埋め込むとしたら、
<script>
　<s:function>
　　...
　</s:function>
</script>
か、
<script><![CDATA[
　<s:function>
　　...
　</s:function>
]]></script>
か、それともSVGみたいにそのまま埋め込むのか、
どれが一番いいんでしょうかね。

XMLベースなんだから当然前者では

>>815
foxは、ローカルの場合は、拡張子を.xhtmlにするとXHTMLとして読み込んでくれるよ。

>>819
foxじゃ無くて普通にローカルのファイルタイプの設定だわ

>>819
お前はちょっと前のレスも読めないのかと

動的ページで「アクセス日：2008/03/05 23:23」みたいに、
ログイン日時やログインユーザ名をヘッダやフッタとして表示したりするけど、
それは何でマークアップすればいいんだろう？
<div>直下にテキストが来るのは何か嫌だし、
かといって単語が並んでいるだけなのに<p>というのもしっくりこない。

dc:date

HTML 4.01やHTML 5の例文見ると、pは文章じゃなくてもokな感じ。
HTML 5だと、headerとかfooterとかいうもっと適切な要素があるけど。

>>822
その例なら、「アクセス日」を<dt>、「2008/03/05 23:23」を<dd>
でいいんじゃない？
あとはcssで横並びにしたり。

http://3d.skr.jp/2d/
こういう<form>+<input>で削除するスレの番号指定するタイプの掲示板作っております。
上の方で投稿者、投稿文は<dl>で定義付けした方が良いと書いてるのですが
投稿者要素の前に付けてる<input>も<dl>内に一緒に入れてもいいのでしょうか？

<dl>好きだなお前ら

まあ、便利だもの

h? が本文の範囲を指定できればそっちの方がいいんだけどね
dl は dt, dd の範囲も明確だしネストの数に制限もないし

>>825
単一の内容が dl にされているのは過剰な気がする
<ul>
　<li title="アクセス日">2008/3/5 23:23</li>
</ul>
こういう気持ち悪さがある

「単一、または複数」ってタイプ（たとえば、連絡先だとか。
通常は１個であることが多いけど、複数もありうるような
型の項目）なら、現状単数でもdlを使っても適切だろうけどな。

まあ、そもそもdiv直下にテキストがくるのは別に悪くない。
(ブロック要素の内容がテキストじゃダメ、なんて法はないから。)

そういえばdiv直下のテキストやインライン要素は駄目とかいう妄言を
時々見かけるが、あれはどっから来てるんだ？

>>832
多分「body 直下のインライン要素は不可」というのを拡大解釈してるんじゃないかな

あるいは div とか li とか dd とかのインライン要素もブロック要素も入れられる
要素においてインライン要素とブロック要素を「同時に」入れるのが行儀悪い
というのを勘違いして「インライン要素不可」と理解してしまったか

>>830
いや、>>822に
>ログイン日時やログインユーザ名を
って書いてあるから、複数の項目があるんだと俺は解釈したが。

>>832>>833
「div直下に……」っていう表現が微妙かもね。
「祖先要素としてdiv以外のブロック要素を持たないインライン要素は不可」
なら頷けるんだけど。
divは論理構造上意味を持たないから、
あるインライン要素が祖先要素としてdiv以外のブロック要素を持たないとすると、
意味的にはbody直下に置かれたのと同じになってしまうし。

>>835
div（やspan）は、構造を付加するための一般的機構であって、
構造上なんの意味も持たない、なんて意味づけはしないよ。
inlineかblockか以上の表現上の意味づけをしないってだけ。

要するに、それ以外の意味についてはあるともないとも意味づけしない。
（意味がないことをHTMLで意味づけされちゃったら、意味のない
構造にしか使えなくなっちゃって、一般的機構にならないからね。）

>>836
ああー、そうか。なるほど。意味がないってのは言いすぎだね。
ちょっと>>835は的外れだった……忘れてくだされ。

>>833
あー有り得るな

「divを外してもvalidなHTMLになるようにすべき」みたいな主張もあるけど
あれもよくわからんな
不適切な要素を使ったり文書を無理矢理HTMLに合わせるように構造変更するよりは
構造だけでも与えられる汎用型使った方がよっぽどいいと思うんだが

>>835みたいな汎用型に意味付けがされてないからって構造まで否定する考え方が
一部で広まってるせいだろうか

<body>
<div>サイト名</div>
<div>見出し</div>
<div>今日は晴れだたｙｐ</div>
</body>

>>839
それはじゃあこれでもいいでしょということ？
それとも適切な要素をひとつも知らないということ？

良いか悪いかは別として、
div直下に文章は変
文章はpに入れるべき

結局あれだ、適切な要素があるならそれを使えってことでしょ。
たとえばメニューを
<div><a>Home</a> | <a>About</a> | <a>Diary</a></div>
とかやらずに<ul><li>なり何なり適切なものを使えと。
で、こういうのが転じてdiv直下にインラインは不可とか言われるようになったと。

>>841
テキストより文字列と言った方が方が誤解を生まなくていいんだろうか
といっても文章だったら何でもpというような考え方には疑問を感じるが

>>842
適切な要素を使えというのは同意する
ただ元文書とHTML仕様を比較して適切な要素があるかどうかは文書作成者によって異なると思うので
div直下のインラインや文字列をまとめて否定する向きには賛同できないんだよな
あまつさえ不可だとする主張には

>>841
文章は不可としたい気持ちはわかるが、単語はどうすんのさ。音節は？

何ループ目だよ

そういえばまとめwikiってどうなったんだと思ったら
誰も書き込んでなくて笑った
そらループもするわな

>>844
何を書く場合なのかしらんが、
単語だろうが音節だろうがそれが本文ならpじゃね？

P は段落だから

pじゃなくてliかdtじゃね？

どっちにしろdiv直下というのは変なわけだ

div直下がokならbody直下もokな気がする

850や851の発想についていけない

oremotuiteikenai

俺はついていける

頭が可哀想に。

怪しい人について行っちゃだめです

div直下は問題ないだろ。
divじゃなくてdlとかulの方が適切だというだけで。

「適切だというだけで」って……
一応ここはStrict-HTNLスレッドってことになってんだけどなぁ。

HTNLじゃしょうがない

Hyper Text N______ Language

>>859
早いな

dlとかulの方が必ず適切というわけでもなかろう

「div直下に文章は変。文章なら必ずp」といっても、文章という言葉が
何を指してるのか一見アバウトすぎる。
文章という言葉が、テキストという言葉の単なる言い換えなら脳内ストリクト系の話だし、
pとして適切なテキストのことなら(strictスレとしては)ごく一般的な話というかトートロジーだよね。

ただ、もし後者ならdivに限った話じゃない一般論なので、わざわざ
div直下云々と限定する必要はないしこの流れでとくに言うことでもない。
（「div直下に連絡先はおかしい。address要素にすべき」とか唐突に言いだすようなもの。）
だから、すくなくとも>841は、前者の脳内ストリクト話なんだろね。

　・div直下にテキストがあることは問題ない
　・body直下にテキストは仕様に反する
　・divではなく他の要素がより多く意味づけできるなら、
　　著者はdivではなくそれを選ぶ方がよい
　　（選ばないのは、Strictスレ的にはdiv厨扱い）
　・以下のルールが適切か否かは著者(というか文書)の意図による
　　・メニューはolかulかdlとする
　・俺ストリクタの脳内ルール
　　・div直下に文章は変
　　・div直下にテキストが来ていいのならbody直下もOK
　　・divを外してもHTMLとして意味が変わってはいけない
というところじゃね？

ただ、慣習や失敗回避として、div直下にテキストがくるような文書の作成と
関わらない（つまり文書自体回避する、そういう文書の作成を禁止する）
というものは一般に存在して、一概に悪いとは言えないと自分は思うけれど、
それはStrictスレで話す論点じゃないだろうし、推奨できる慣習でもないだろね。

「他に適切な要素がなくて、div直下にプレーンテキストを置かざるを得ない状況」
って具体的にどんなもの？
無い知恵絞って考えてみたが俺には思いつかなかった。
まあどういう場合に何が適切な要素かっていう判断は人それぞれだから
ちょっと無理のある質問かも知れんけど。
個人的な考えでいいから誰か聞かせてほしい。煽りとかじゃなく。

>>864
今のHTML 5のfigureとlegendの構造なんかを既存の勧告仕様で実現するとして
legendの内容となるものについて既存の要素で意味付けするのは不適当だと著者が思えば
legendをdivで代用することも考えられるし
WAI-ARIAとの絡みでもいろいろあると思う(自分は勉強不足なのではっきりは言えんが)

なんでもかんでもdivを避けて既存のHTML要素のどれかに当てはめる人もいれば、
「DTD上通るからとむやみにpで括る、ってのは不適切じゃね？」と思う人もいる。

会話文だって、仕様にある例とくらべて、「この会話文は定義リストと
しては不適当だ」と著者が意図するならdlじゃなくなる余地がある。
（仕様にある状況とは異なる状況であると見なす場合の話ね。
　「仕様が間違ってるんだ。俺が仕様だ」って話じゃなくて。）


それとは別の話だけど、たとえば「divより表現するのに適切な要素があるなら
その要素としてマークアップすることを推奨する」とかの類の公式の文言って
どっかにある？
　・著者は、より詳細な意味づけのかわりに汎用的な意味づけを選択してもよい。
って考え方について、仕様として（またはW3C的に）通る余地を残しているか否か、
という話なんだけど。

>>864
個人的によくやるのは画像だけのアフィリエイトリンクで
本文の特定の場所に置くのが不適当な飾り画像的なもの

alt 文字列は単なる商品名なので本文の文脈に組み込まれても困るし

altに「○○アフィリエイトリンク用の画像」とでも書いとけ

>>865
どうも。
なるほど、確かにそういう使い方なら色々ありうるね。
よく考えたら俺も（プレーンテキスト云々とは違う話になるけど）、
<section>の代わりに<div class="section">とかやってるし。

>>867
ごめん、ちょっとよく理解できなかった。
本文と関係ないってことが判るような書き方をすればいいんでないの？
逆に、div使ったからって本文と関係ないってことになるわけじゃないし。

本文を構成する構造のなかに同列にはぶち込みたくない、という話でしょ。
「本文を構成する構造」とかいう意味づけにはならないけど、
じゃあごっちゃの構造にしていいかというとそうじゃない。

javascriptとかで書き出すタイプのアフィリエイトとか広告だと、
そのまま書きだされるとこもあるよな。

話は逸れるけどcanvas要素が便利すぎてしっこちびりそう。

そんなもの何に使えるんだ？

何に使えると言われても何にでも使えるとしか。
動的なグラフ、チャート、やろうと思えばなんでもできる。

画像とかだけをマークアップするとき
　<p><img></p>
ってやると、「画像って段落なの？」 って疑問に思って
　<ul><li><img></li></ul>
こうする人もいるくらいだけど、
それいったら別にリストにする必要もないんだから、
　<div class="image"><img></div>
とかでもいいじゃん、っては思うんだよね。

別に img じゃなくても object でも、広告でも、テキストでも、カウンターとかでもいいんだけど。

やっぱりdiv直下にimgは気持ち悪いからfigureは必要だな。

canvasは装飾とレイアウトされたテキストぐらいのサイトしか作らない
ストリクタには要らないし、必要性も感じないだろうさ
機能をつけたくてもそのためにマークアップを追加したりする事が出来ない性だし、
やりたくても出来ないって意味の影響も大きいだろう

canvasってIEで対応してなくね？

IE気にするようならストリクタやってなくね？

htmlだけなら崩れる程度だからいいけど、Javascriptが絡むと1か0かだからな。
気にせざるをえないのが現実。

>>877
createElementとかで未対応要素にも対応できるように可能らしい。
googleが便利なの作ってる。

>>875
俺は気持ち悪くない

> 機能をつけたくてもそのためにマークアップを追加したりする事が出来ない性だし、
> やりたくても出来ないって意味の影響も大きいだろう
>>876は書いた文書を改訂しないんだろうか。

？
改訂するときは普通にマークアップすればいいんじゃ？

>>874
>ってやると、「画像って段落なの？」 って疑問に思って
段落でいいじゃん

・エントリ名　（日付け）
・エントリ名　（日付け）
・エントリ名　（日付け）
とか
・カテゴリ名　（件数）
・カテゴリ名　（件数）
・カテゴリ名　（件数）
とかは

<li><a>Strict-HTMLについて <span class="date">2008/03/25</span></a></li>
とかを並べるのってどう思われますか
表のほうが適切ですか

liでいいんじゃね？

エントリ名やカテゴリ名を示すことがそれのメインだろうから、
インラインでちょっとした補足事項が付記してある形なんで、
そういうふうにspanでマークアップするのがいいと思う。

簡単な参考情報というより対象に対するテキストの方が主体になるdlや、
データをまとめて一覧として提示することが主題となるtableと比べると、
olやulの方が適切だと思うよ。
# 主体になるとか主題になるとかは仕様にある話じゃなくて、HTMLの外の
# 一般論でのことなんで、もしそういう（主体になるとか主題になるとかの）
# 点が異なってくる状況ならば、この限りじゃないけれど。

paragraph
段落、パラグラフ
[語源] para(＝beside) ＝ 意味の切れ目を表わす

ttp://home.alc.co.jp/db/owa/etm_sch?unum=3290&rnum=213&stg=2

仕様書には厳格な<p>の定義が見当たらないので、
語源辞典でparagraphを調べるてみると、「意味の切れ目」が語源らしい。

<img>も一つのページの中の文章を構成する一部分だし、
それ自身で一つの意味を示しているのであれば、
<p><img></p>でも間違いないような気がする。

そのimgがないと前後のつながりが成り立たないような場合はpでいいと思う。
そうでないならimgの為だけにpはちとちがう気がする。

でも他に適当な要素がないのなら
<div class="image"><img></div>とか<div class="word">単語</div>とかしなくても
<p class="image"><img></p>とか<p class="word">単語</p>でも良い気がする
<ul>とかは間違ってる気がするけど

俺はそんな気がしない

せめて「そんな」が何を指してるのかくらい書いてくれよ…

気持ち悪いとか気がするとか
俺のフィーリングが全てだ！的な主観丸出しのレスには「そんな」レスしか付きません

>>887
HTML仕様の範疇外での意味論がまずあって、
具体的なマークアップはそれにも左右されるってこったな。

>>889
pも汎用の要素じゃないんで、消去法で選べると考えてるのが間違い。
addressとpのように役割の重複する要素はあるにしろ、>887や>888のように
それらの意味づけと、それがマークアップ箇所に適切かどうかを考えないと。

「他に適切な要素がないのなら…」って、あぶれたゴミを突っ込む
要素かなにかだと勘違いしてない？

そうだよな、あぶれたゴミを突っ込む要素はdivだよな

このスレの様ですね

<form>
　　<p class="field"><input type="button" value="次へ"></p>
</form>

みたいに<p>を使う事は個人的には結構ある。
文章として一定の意味が込められたプレーンテキストを、
マークアップすることで構造を示すというのがHTMLなんだから、
imgもinputも文章の中にあって意味を伝える一要素という点では同じで、
HTMLの文章の基本的な単位となる<p>で括ることにあまり抵抗感は無い。

もっとも、HTML5では映像は映像、写真は写真、絵は絵、ボタンはボタンという
「部品」の組み合わせで、カラフルなオモチャを作るのが目的のようだけど。

カラフルなオモチャ？

白黒世代なんじゃね？新しかったり見栄えがよかったりするのは全部「カラフル」。

それにしても、"次へ"ボタンを脳内仕様と不条理な言葉の連想文で言い訳したり、
その口でHTML5を「部品を組み合わせたオモチャ」と言ってたりして、支離滅裂すぎだ。
仕様書がヘボいせいでそれを遵守するのがうまくいかないからといって、
当人しか参照できない脳内仕様書を当然のように持ち出しちゃダメだろ。

時代の変化についていけない老害は消えていくだけだと思うよ。
HTML5なんかは妥当な進化だろう。
物理マークアップに逆戻りとか言い出しそうだけど、本質は全然違う。

つまりIEもといMSの尻拭い

要素型とかコアの部分でMSの尻拭い部分ってあったっけ？
DOM-0の標準化辺りはスレ違いだし

自分の気に食わない流れは全部MSのせいだと思ってるんじゃね
HTML5を推してるのってどっちかというと
IE以外のブラウザメーカーじゃなかったっけ

もとはApple。
でもWebページ用ではなかった。

確かHTML5の正式版が出るのは10年以上先だろ。
文字通り、夢に溢れた未来のお話って訳だ。

>>904
http://www.w3.org/html/wg/
> Milestones
> ...
> 2010-09 HTML5 Recommendation

>>904
90年代からの書き込みですか

もう既に一部はIE以外には実装されてるし、
未来のお話と片付けるのもなんだかなと思う。
IEでも使えるように出来るhackのノウハウまであるのもあるしな。

仕様書軽く斜め読みしたけど、覚えることが多くて面倒そうだわ
印象だと、今までの文書にマークアップする感じから、
ブラウザで扱われるコンテンツをマークアップする感じだな

OldTypeのストリクタは発狂しそうｗ

勘弁してくれよ年度末で忙しいのにまたやることが増えるのか

> 覚えることが多くて面倒そうだわ
アバウトすぎる要素と狭すぎる要素しかなくて適当にやっても言い訳できたのが、
いろんな意味づけが出来るようになるから使い分けるのが面倒なんだろ。

要素が少ないことに発狂して俺ストリクト仕様に走って、それに慣れた>896とかは
面倒になって発狂するだろうけど、常々意味づけの想定の狭さを嘆きつつも
俺ストリクトに走ったりしなかった古くからのストリクタは狂喜するんじゃね？

古くからのHTMLが想定していたような論文と記入欄だけの文書しかマークアップせず、
しかもそういうマークアップのされた文書しか利用してないような本当に古いストリクタだと、
HTML5だろうが関係ないわな。
今WWW上にあるHTML文書なんてほとんど利用してないはずなわけで。

W3Cの陰謀だったんだろうな、
論文マークアップ用のHTML(>>1)を主に勧めてきたのは。
Webに公開されるのは論文だけでいいという。

>>905
2022年正式勧告って数ヶ月前に見たんだがガセだったか。
IE6が4割、IE7が2割、という非対応ブラウザが過半数な状況を1年で出来るんだろうか。

>>910
日本語でおｋ

×1年で出来るんだろうか
○1年で改善出来るんだろうか

6と7合わせて9割だろ？

webページの作成について質問です。
htmlのページの簡単なものなら作れるようになったんですが、まだ分からない点が多くあります。その質問にきました。
例えば、会社の会員登録ページのようなページもhtml言語を用いて作っていると思います。
その、氏名や、メールアドレスを打ち込むような場所ありますよね。この書き込み画面で言えば、「　名前：　の次の空白のところなどです。
分かってもらえれば光栄ですが、、簡単に言えば文字を打ち込む場所です。それを使ってwebページを作って、相手がそこに打ち込んだ情報が自分の下に届いたりするようにしたいです。
本当に日本語力がないので分かってもらえれば光栄です。お願いします。

>>915
<input type="text" name="name" value="名前を入力してくだしあ">
<textarea>メッセージを入力してくだしあ</textarea>

これらの表示と、入力されたデータをサーバーに送るところまではHTMLのお仕事
データを受け取って処理を行うのはサーバーサイドのプログラム(Perl,PHP等)

なんとなくレスしてみたけど、そういう質問はWebサイト制作初心者スレの方で
ここStrictスレだから

>>916様
ありがとうございました！！ちなみに相手が入力したデータをメールで送って貰うように出来たりするのはありませんか？
こっちでするのは間違っていると思いますが…

できるけど、それもサーバーサイドの処理になる

なるほど、ありがとう御座いました…！もうちょっと勉強してからにします

まあ、CGI なり PHP なり使うことになるんだろうけれど、このスレで訊いた以上、吐き出すソースが Strict になるよう努めなさい、ってこった。

みんな優しいな

>>914
ttp://www.w3counter.com/globalstats.php　によれば、
IE6：39.00%、IE7：22.67%で、二つあわせても6割超ぐらい。

>>912
WHATWGは2022かそれより後って言ってるな
使いたい機能の仕様での完成度と実装状況を見て使えって感じみたいだ