1 :
◆eUtysLtYW. :
2006/09/19(火) 20:35:39 ID:yyMcszw4
2 :
◆eUtysLtYW. :2006/09/19(火) 20:36:35 ID:yyMcszw4
3 :
Name_Not_Found :2006/09/21(木) 12:10:55 ID:OXGKUuJP
前スレ落ちたか
みたい。 埋めときゃよかったな。
ちょっと間が空けば落ちてしまうな。
どういう条件で落ちるのかいつも忘れる。 板によって違うんだったかな。
XHTML2.0がいつ勧告されるか賭けようぜ
950超えて一定時間で落ちじゃなかったっけ?
>8 980のはず
スレ立て後即死判定
このスレは特にだが、話題がないとレスがなかなかつかない。 誰か話題投下キボン
HTMLを鳩丸と呼ぶのはどう考えても邪道な件
まあ、ばけらさんもあんまりStrictじゃないし。
これならいい? <abbr title="Hyper Text Markup Language"><abbr title="HTML">鳩丸</abbr></abbr>
>>14 みたいに、ありとあらゆる略語要素にtitle属性で原形を記すのは気持悪いと思うんだがな。
そりゃ、略語の原形を伝えたい場合はそれで良いと思うよ。
でもなかには「エアコン」とか「リモコン」という、略語で定着した語句まで、いちいち略さない形を記している奴も居るのに驚いた。
多くのユーザーエージェントは、要素にフォーカスするとツールチップで表示してくれるから気持悪くないかも知れないが
これって「エアコン (エア・コンディショナー)」とか「テレビ (テレビジョン)」とかいちいち記しているのに等しいぞ。気持悪くないのか。
もっとひどいのが「これをSEOのため」と騒いでいる奴だ。
HTMLをちゃんと理解していないのか。困ったものだ……。
誰も君の好みなんて聞いてませんぜ
要素に記述されたtitle属性は、どの程度、閲覧者に伝わるものと考えられますか? 例えば、ある小説の文章を引用して記述するときに 「<span title="ウォッシュ">波</span>の乱れを感知したんだ」 (中略) 「<span title="ウォッシュ">洗濯</span>って?」 「時空の<span title="ウォッシュ">波</span>だよ」 などのように、title属性が閲覧者に「必ず伝わるもの」とした書き方をしても大丈夫でしょうか。 それとも、「伝わらない事もある」と考えて、例えば上記の例の場合には「括弧書き」などをすべきでしょうか。
>>17 普通の文書と同じように考えて「括弧書き」がいいと思う。
つか、ユーザエージェントも括弧書きのような描画をしてほしい。
abbrのこともそうだけど。
そこはルビにしたいなあ。カッコだとやっぱテンポがね。
それは見栄えに関わる話
見栄えを考慮しちゃいけないわけではないよね。 どっちだって問題ないんだから。
本気と書いてマジと読ませる場合はruby! 波と書いてウォッシュと読ませる場合もruby!
ハトマルと読むなら、ACRONYMだろ。
<br>って置き換え要素じゃないんですか?
剣道の記録ってHTMLでマークアップできないですかねぇ。 剣道では1本目に取得した技を○で囲むんですが、そのままではマークアップできませんし、 画像にすれば代替文字列がかけません。
「丸で囲むこと」に意味があるの?他と区別が付けばいいだけなら強調とかすれば。 あとはスタイルシート側で背景画像を配置するとかボーダーをつけるとか。
☑
28 :
25 :2006/09/24(日) 22:32:51 ID:???
>>26 どうもです。
普段鉛筆で記録しているときは○で囲むので、○じゃないといけないと思ってましたけど、
よく考えれば他のと区別できればなんでも良いかもしれませんね。
emにCSSでbackground付けることにします。
そういえば、中学のときに剣道をやっていたなぁ。
>>28 emの意味である強調にした所で、
それが取得した技と言う、一般的な認識になるの?
筆記とWEB上での見栄え的な表現方法が、そもそも違う、と思う。
マークアップ言語的に言えば、
その分野をRDF的に出来れば良いと考えるが。
紙に ○ したってそのルール知らない人から見ればわからんわけで 「一般的な認識」 じゃあないし。
>>27 のいうように <input type="checkbox" title="最初に取得した技"> や画像をその技の前か後につけても問題ないんじゃね。
KendoMLのスキーマ作って、HTMLへ変換するスクリプトorスタイルシート(XSL)だ。 HTMLは文書のためのマークアップ言語。
SVGでおk
>>31 > 紙に ○ したってそのルール知らない人から見ればわからんわけで 「一般的な認識」 じゃあないし。
紙に○ってのは元テキストレベルの話なんだから、emと比べるのは的外れだろ。
それを同一視するのは、数式で累乗を上付文字で書くのを「知らない人がいるなら一般的ではない」
って言い張るようなものだ。
(文書の主な閲覧者にその表記ルールを知らない相手も含みたい、というなら話は別だけど)
で、フォームの入力でもないのに
> <input type="checkbox" title="最初に取得した技">
ってのは論外だろ。よりによってStrictスレでよく言えるね。
>>28 それでもいいし、技の後に*印でもおいといて、注釈をつけといてもいいと思うよ。
元テキストで表現するかHTMLとかCSSで表現するかの違いだ。
好意的な解釈をすれば、 剣道の記録データは、少なくとも本人が、利用しやすい形で保存してあって、 それをHTMLに変換した時に、どうマーク付けをすれば好いのか、 を、聞いているだけじゃあないかな。 というか、好意的に解釈せずとも、そもそもここはHTMLスレだから、 HTMLのマーク付けの話に終始しておけば間違いないだろう。 だから、CSSでどう飾るかなんて話さえ、聞いちゃいねえよヴォケ、な話だろう。
<input type="checkbox" title="最初に取得した技"> これって視覚情報のためのマークアップじゃね?
<img src="maru.png" alt="最初に取得した技" /> ? ってか 「テストの○×ついた答案をマークアップする」 ようなもんじゃないの、これは。
>>38 > テストの○×ついた答案をマークアップ
<dl>
<dt>問1</dt>
<dd>1+1</dd>
<dd>3</dd>
<dd>不正解</dd>
<dt>問2</dt>
<dd>2*3</dd>
<dd>6</dd>
<dd>正解</dd>
:
とかどうでつか?
(´・ω・`)
>>25 >剣道では1本目に取得した技を○で囲むんですが
メディア媒体が違うんだから同じようにするのは難しいだろ。
どうしてもっていうなら画像で表現するしかないと思う。
複数のサイトに組み込まれる予定のコンテンツをコーディングしてるのですが、 組み込まれるhtmlの文書構造が不明なので、見出しレベルを指定できません。 このような場合、どのようにマークアップすればよいでしょうか? <p class="クラス名"><strong>見出し</strong></p> くらいが無難ですかね?
せめてDIVにしようぜ(´・ω・)
>>44 アドバイスありがと。
たしかにdivの方がいいですね。pにする意味ないし。
>>43 レベルは組み込むほうが設定するべきものだから、
埋め込まれる側が気にしてはならない。
そこで<xhtml2:h>見出し</xhtml2:h>
%URI;って、書けるURIって1つだけ?
ストリクタ自体が、基本的にただの自己満足の賜物だしな。 仕様より仕様に忠実なのを目指してる時点でそうとしか言えない。 だが、それもまた良いとは思うけどね。 色々と参考にはなる。 たまに居る他人を小馬鹿にしたような言い方や、 strictを強要するような馬鹿さえ居なければだけど。
>>49 そんな特殊な例を持ち出されても困るwwwww
>>52 >たまに居る他人を小馬鹿にしたような言い方や、
>strictを強要するような馬鹿さえ居なければだけど。
そういう人間がいない世界を知っているなら、ぜひ教えてもらいたいねえ。
脳内以外で。
商売でやってるんなら小馬鹿にされてもしょうがないと思う
http://pc8.2ch.net/test/read.cgi/hp/1157971088/563 こちらのスレで質問したのですが、スレ違いなのでStricterにお聞きします。
コピペで申し訳ないのだが、
攻略の説明文で、コントローラー入力の部分のマークアップに、
<p>ここで<kbd>○</kbd>ボタンを押す。</p>
という記述はW3C的に変だと思う?
後、ゲーム中に出てくる本文を記述する時、
<p>ここで<q cite="ゲームの名前">さあ、ラスボスを倒そう!</q>を選択する。</p>
ってするべきなのだろうか?そうするとサイト内引用だらけになってしまうという
問題もでてくるんだが。。。
58 :
Name_Not_Found :2006/10/01(日) 19:59:57 ID:Ul54UxeZ
>>57 Another-HTMLで、確認したら?
?
>>57 <dfn>○ボタン</dfn> とか <code>さあ、ラスボスを倒そう!</code> とかでもありじゃね?
codeでなくsampが適切だろう。
どっちか迷ったんだけどね。
samp は 「出力例 (sample output)」 だから、
ユーザーに示したい、これと決まったコードを示すときは……
というか、たしかに 「さあ、ラスボスを倒そう!」 はプログラムの出力であるんだけれども、
ユーザーからしてみれば、それは出力というよりはコードなわけで、
たとえば、
「<samp>たたかう</samp>を押すと、たとえば、<samp>敵に10のダメージを与えた</samp>とでます」
これより
「<code>たたかう</code>を押すと、たとえば、<samp>敵に10のダメージを与えた</samp>とでます」
のが自分的にはしっくりきたので
>>60 はそうしたのだった。
どっちが適切なのかはちょっとわからん。
入力コードだから<kbd>○</kbd>でいいと思う。 codeは何でそうなるのかわからん。ソース片じゃないだろ。
日本語の問題なのかも知れませんが、紙媒体の文書とHTML文書では メディアが違うのでここで質問させてください。 皆さんは、「文書の最終更新日」をなんと表記していますか。 いろいろ見ていると「最終更新日」(一番多い)や「最終改訂日」としている人が多い様です。 それから、これはどのような要素になるのでせうか? いまのところ私はP要素にしています。 <p>最終更新日: YYYY-mm-dd H:i:s</p>
<dl> <dt>最終更新日</dt> <dd><dc:modified>2006-10-01T21:54:00+09:00</dc:modified></dd> </dl>
ul-liかな
こうしん【更新】(名・自他スル) 新しいものに改まること。また、改めること。 「記録を―する」「免許証の―」 かいてい【改訂】(名・他スル) 書物などの、誤りを正し不足を補うなど、内容をよりよく 改めること。―― 旺文社 国語辞典より さて、どちらを使うべきか……。
改訂ならinsやdelでマークアップして、日時はdatetimeに書くから無問題。
自分はdlかな。
dlだな。
dlだなあ 並列の関係だし
もう面倒なので、サイトナビゲーションも更新情報も廃止しました!
検索窓はどんな感じにマークアップしたらいいだろう。 特にinput type="hidden"の扱いに困る。
なんで?
inputはインラインなんだから、他のと並べちゃえばいいじゃないか。 他のも別のddやらpやらで囲んであるんだろ。
検索語句入力欄や掲示板の書き込み・コメント投稿の入力欄は dtにフォームコントロールが何かというものを書いて ddにフォームコントロールを置く、ってのはやるけど 送信ボタンに対応するdtはあるのは変だから送信ボタン部分をpかul,liでやって そこにtype属性値がhiddenのやつも置けばいいんでない?
57だけど、回答サンクス。 <kbd>って、プレイステーションなんかのゲーム機での入力でもいいんだね。 パソコンじゃないとだめだと思っていたので、これからガンガン活用します。 <samp><code>も<q>の変わりにいいね。参考になりました。
79 :
74 :2006/10/03(火) 21:54:45 ID:???
例えば <dl> <dt>example.com内を検索</dt> <dd><input type="text"></dd> <dd><input type="submit"></dd> <dd><input type="hidden"></dd> <dd><input type="hidden"></dd> <dd><input type="hidden"></dd> </dl> とかだとマズいのかな。hidden他のinputと並べちゃったほうがいい? input type=hiddenのhtml的な位置づけがよくわからない。
Formに関する議論は過去ログになかった?
おれは
>>77 のタイプかな
>>79 も dt要素と一組になってるならいいんじゃないか
ただ hidden は submit と同時に送信されるから
やっぱりセットにする
>>77 のタイプ派だな オレは
というか
>>79 の例なら、キャプションは legend にして、
inputだけ p でまとめりゃいいんじゃね?
なんでわざわざP使うのかわからん。DIVでいいやん。
おやおや
>>82 おやおや
逆だろ
なんでわざわざDIV(とその中にP)使うのかわからん。Pでいいやん。
pは変。段落じゃないし。 divは変。他の要素で置き換えられるし。
他に使うもんないっしょ dt ddでだいたいはできるけどね 送信ボタンとかは p 以外になんかある? tableで、とかいう人もいるけどtableは明らかに違う気がするな
フォームが並んでるんだったらリストだろ。
>>86 テーブルでも縦横のセルの並びに意味があるんだったらテーブルだろう
>>79 はないでしょ
リストもテーブルもおかしいから
p でいいと思うけどな
そんなこといったら全部おかしいぞw p しかないだろう
そろそろ釣りだと気づけ
釣りですますなら書くなよw
ってか <fieldset> でいくね。
<input type="hidden">って、ブロック要素の中に 他の要素や文字列は入れなくても問題ないの? マークアップの為のマークアップになっちゃうけど。
>>94 は?
それこそ釣りだろw
>>95 だから、ほかの hidden と送信ボタンをひとまとめにする
っていう話だったんだよ
>>94 fieldset直下にインラインはdiv直下にインラインと同じようにストリクタには忌避される。
> 「liやddの中をp要素でマークアップしなければならない」ということの根拠は?
li要素内とか関係なく段落は全てp要素でマークアップするべきである。li要素内とかdd要素内だけ例外とするのは可笑しい。
>
>>98 のリストは段落の一部を引用しただけで段落ではないと思うが、どうか?
それはそうかも知れないが、li要素内が本当に段落だとしてもp要素でマークアップする人は少ない。
> 真名垣氏は厳密なStricterではないと思う。
本当に厳密なStricterって居るんですか?
一応、私の中での"厳密なStricter"の基準
・p要素省略禁止
・dl要素内はdt要素とdd要素が交互に出現する。
・lang属性の省略を禁止
・object要素を介してブロック要素を含めるのは禁止
---
2番目について補足
dd要素内が段落ならdd要素内にp要素を並べる事によってdd要素の連続を防ぐ事が可能。
それ以外のdd要素の連続はdd要素内に順不同リストを入れる事によって解決します。
dt要素の連続は原文の改変で防げるかと……
>dt要素の連続は原文の改変で防げる お前全然Strictじゃないな。たかがマークアップ言語が原文改変してどうすんだ。
> お前全然Strictじゃないな。たかがマークアップ言語が原文改変してどうすんだ。 意味的にdt要素が連続する様な原文は文章自体が不自然な気がする。 其れを自然な文章に修正する。それだけ。 不自然な文章を修正するとマークアップした時にdt要素が連続することは無い。マークアップする時に修正するのではなく、不自然な文章を修正した後にマークアップする。
>>100 そんなことがDTDのどこに書いてあるか教えてくれ。
あるいは自分でSchemaを書いたのなら見せてくれ。
>意味的にdt要素が連続する様な原文は文章自体が不自然な気がする。 >其れを自然な文章に修正する。それだけ。 気がする、だけで原著者の意図から外れて構造いじっていいのか? >不自然な文章を修正するとマークアップした時にdt要素が連続することは無い。 お前が「感覚的に」不自然だと感じた文書を自分の都合の良いようにいじるだけの話。 dt要素的な語句を意図的に操作するんだから連続しないのは当たり前。いじるのはお前だから。 それが正解(および妥当)だっていう保証も根拠もないだろ。 >マークアップする時に修正するのではなく、不自然な文章を修正した後にマークアップする。 言葉のあや。卵が先でも鶏が先でも「マークアップにあたって改変した」ことになる。
正しくない文章は正しいマークアップを出来ないんじゃね? 別に原文を校正するのは(勿論注意書きする必要は有るけど)必須な気がする。
改変と校正の差異に注意されたし
>100
そもそもリスト中に段落構造が出てくることはそうそうないと思う。
自分が見た限りでは5月上旬の無為徒食日記くらい。
>>105 上手くマークアップ出来ない文章はあるだろうけど、「正しくない」とは言い切れないと思う。
しかし、私は上記に加えて、
・水筒
・タオル
・ちり紙
・ビニールシート
・ビニール袋
・雨具
も、必需品ではないかと思うのだ。
なんてのがいい例。
>>107 それをリストにするのがおかしいんだってば。
>>107 の「いい例」は
<p>しかし、私は上記に加えて、</p>
<ul>
<li>水筒</li>
<li>タオル</li>
<li>ちり紙</li>
<li>ビニールシート</li>
<li>ビニール袋</li>
<li>雨具</li>
</ul>
<p>も、必需品ではないかと思うのだ。</p>
ってマークアップするの?
漏れ、よくこういう途中で文が切れて間に別のものが入ってまた途中から文が続く…って書き方を
よくするんだけど、そういう今もそんな書き方なんだけど、
そういう場合は前半で切れている文(
>>107 の「いい例」は)と
後半から続く文(ってマークアップするの?)のそれぞれを<p></p>でくくっていいの?
それぞれだけだと文章として成り立たないっすよね…?
リストにしないよ。それだけのこと。
112 :
110 :2006/10/06(金) 07:32:21 ID:???
>>111 え?
>>110 の場合はそもそもリストの話とは関係ないよね。
>>110 の場合はpreかな。
また場合によっては
<p>
>>107 は107で</p>
<blockquote><pre>
しかし、私は上記に加えて、
・水筒
・タオル
・ちり紙
・ビニールシート
・ビニール袋
・雨具
も、必需品ではないかと思うのだ。
</pre></blockquote>
<p>と言っている。</p>
といったケースもあるだろうし。
今回も、この二つに分断された「
>>107 は107で」「と言っている。」や
さらには「また場合によっては」「といったケースもあるだろうし。」を
どうマークアップすればいいのか…ということが先ほどから気になっています。
今までは前後それぞれをpでくくっていたけど個別に取り出すと文章になっていないし…。
小説などでも文の途中で会話文が入った場合は 句点(。)じゃなくて読点(、)のあとでも改行して 行頭にかぎ括弧(「)を持ってこないといけないルールだけど <p>沈む夕陽を見つめ、</p> <blockquote>(恥ずかしい言葉)</blockquote> <p>と彼は言った。</p> こうなるのかなあ。会話文が短ければ <p>沈む夕陽を見つめ、<q>(恥ずかしい言葉)</q>と彼は言った。</p> などとしてスタイルシートなどで<q></q>の前後に改行を入れてもいいのかもしれないけど。 (この文章も「マークアップの例」のせいで文章が分断されていますね。)
>>109 「おかしい」理由をもっと明確に。
>>110 p要素の中にブロックレベル要素(例えばul要素ね)を含む仕様が検討されてます。
>>113 小説は丸ごとpreか、span要素を発言に割り当てるのが妥協案でないかね。
日曜日にぼくとまさおくん、あきらくん、たかしくんの四人で動物園に行った。 まさおくんとあきらくんは待ち合わせに遅れて来た。 みんなでさるやきりんやぞうを見た。ほかにたぬき、きつね、ポニーなんかもいた。 どうする?
小説の引用じゃなくて自作小説もpre?自作ポエムはpreでもいいけど。
素の文ありき、じゃなくてマークアップありき、の人は”マークアップのための文”を作ります。 <p>彼は沈む夕陽を見つめた。</p> <blockquote>(はずかしい言葉)</blockquote> <p>そう彼は言った。</p> <p>彼は沈む夕陽を見つめてこう言った。</p> <blockquote>(はずかしい言葉)</blockquote> このような具合です。
でしょ? 日曜日に動物園に四人で行った。メンバーは以下である。
マークアップ言語によって自然言語が縛られるこんな世の中じゃ
>>114 > p要素の中にブロックレベル要素(例えばul要素ね)を含む仕様が検討されてます。
この仕様が採用される前(今)はどうマークアップすればいいんですかー
>>119 ぽいずん
いや、だからリストにしたいがために 「と」や「や」や「、」を省くのも不自然だと。
リストじゃない例も出ているのになんでリストにこだわる
いや一緒だと。
>>115 それはそれでいいんじゃない?作文でしょ?
で、今は
>>114 > p要素の中にブロックレベル要素(例えばul要素ね)を含む仕様が検討されてます。
の部分はどうマークアップすればいいのよー!
採用前は地の文章を書き換えるの?んなわけないよね。
>>124 だから、それをむりやりリストにしたい人がいるんでしょ?
そしてリストにこだわらせないで下さい。
>>110 ,112,113
このあたりは今はどうマークアップすればいいんですか・・・?
<p>前半、</p>
<block>ブロック要素</block>
<p>後半。</p>
これで問題ないですか?
TeXなら万事解決
>>114 > p要素の中にブロックレベル要素(例えばul要素ね)を含む仕様が検討されてます。
検討されているってことは日本語だけじゃなく他の言語でもそういう文の書き方があって
そんな文をうまくアークアップする方法が求められているってことっすよね?
・・・で、今はそんな文をどうマークアップすればいいのー??
>>127 自然言語として自然なら(なんだそれ?)無理やり分断しなくて良いんだよ。ひとつの段落なんだから。
あと前出のセリフはblockquoteじゃない。
>>122 >>119 何でもかんでもマークアップ言語に添ったものが正しい文書構造ではないのだし、
マークアップできないから順序を入れ替える、なんて馬鹿げてる。
もちろん地の文書がある程度のレベルに達しているものに限って、の話だが。
>>125 XHTML拡張でもしたら?
仕様は適宜変更されるものだし、暫定的なものに頼って文書書き換えることはないよ。
現状のルールにそぐわないときのためにdiv要素やspan要素使うとか?
そのへんはどこまで自分に妥協を許すかによるけども。
>>126 文中からむりやりリストを省きたい人がいるんでしょ?
>>131 じゃあ文中の項目を全部リストでやれば良い。複数の可能性のある単数の項目も全部リストでやれば良い。
だからこだわらせんな。ほっとけ。
四の五の言わずに面倒な話題だと思ったらスルーすればいいのに。 スレ内の全話題に自分が参加しないと気が済まないのかい?
>>133 書かれたから返したんよ。そういうおまえさんもほっとけない参加したがり屋の同類じゃないか。
粘着するぞ。
うそ。
わかった。ごめんなさい。
じゃあね。
リストの中にpを入れなければならないとか何とかいう話はどうなったの? 言い出した人は根拠は無くただ気持ち悪いってだけ? フォームのhidden属性値のあるinput要素の話は 送信ボタンと一緒にliやpの中に入れるってことでFA?
>>135 Paragraphならリスト内でも pで括る
ただそれだけでしょ
箇条書きまで pで括るのは違うと思う
hiddenは送信ボタンとセットが無難だと思うな
無難なStrictってなんなんだぜ?
>箇条書きまで pで括るのは違うと思う 箇条書きはdd要素内に順不同リストを入れるのでは?
>>137 とりあえずDTDだけに従うStrict
質問です。 プログラムソースをolでマークアップするのは間違いでしょうか。 BASICではプログラムが行単位で評価され、その順序にも意味があるので。 行番号自体にも意味があるからtableで番号と内容に分けるのも健闘しているのですが。 昔、BASICをちょっとかじって以来コンピュータからしばらく離れ、 最近、趣味でHTMLを書くようになって、このスレをのぞいています。 「LIST」というコマンドを使ったのを思い出して質問しました。
<xhtml2:l>ライン</xhtml2:l>
preがそのための要素だからpre使えばいいんでね?
>>140 olは番号付きリストじゃないよ。UAが勝手に番号を付けているだけ。
preとcodeかな……
<div>ああああ</div> <div><p>あああ</p></div> だと、前者はやっぱり良くないの?
そんな唐突に
>>145 Strict DTDに従えば一応はStrictじゃね?
>>146 正直このスレにいる人間のレベルではわからない気がする。
そういうレベルの高い質問は、ほかのスレで…
ここは、隔離スレなので…
バカらしくてスルーされたのにw
>>146 前者だと本当のStrictにならない。
divはグループ化の要素であって、直にインライン要素などを含ませては行けない。
よって、前者はStrict違反になる。
この辺は難しいのか誰も答えられてなかったので、
私が変わりに答えました。
何かほかに聞きたいことが有ったら、とあるpro様へと本文に書いてもらえれば、
仕事の合間にレスします。
>とあるpro様 頭が可哀想な人なんだな
>Strict違反になる。 >この辺は難しいのか誰も答えられてなかったので、 >私が変わりに答えました。 ハゲワロタ
>divはグループ化の要素であって、直にインライン要素などを含ませては行けない。 え? どの仕様書にそんなことが?
>>157 ないよ。
ないけどそうなの。こだわりたいし、実際そうであるべきと本気で思ってるの。
俺達ヘンだから隔離されてるの。生暖かく見守ってね。
^^;
>>157 divは単なる枠だからかな。
つまり、div直下にインライン要素を入れた場合、
body直下にインライン要素を入れたのと同じ状態ということか。
> 各々、内容が行内であるか(SPAN)ブロックレベルであるか(DIV)は定めるが、他のプレゼンテーション的語彙を示すことはない。
ということが、そのことを示していると言えるのではないだろうか?
枠w
じゃあ <object> とか <button> とか囲むときってみんな <DIV> 使わないで <P> 使ってるの? 「<P> は文章の段落」 としてる人はその場合何使えばいいと?
>>162 文書の本体は文章じゃなくてもいいんだ。段落も文章じゃなくてもいい。
「文」の文字で錯覚してるんだ。p要素の段落は、作文や小説の段落や説や章とはちょっと違うと本気で思ってる。
>>162 pを勝手に文章の段落にしちゃってる奴はここにいないでしょ。
>>162 <button>ってすでに、ブロックレベル要素の<form>の中にないか?
えー、じゃあ 「文章の段落」 をマークアップするときはわざわざ <p class="文章"> みたいにやってるの?
<p class-"object"><object /></p> とかして?
ここでスタイルの話になるのは関係ないとは思うけど、利便性の問題として
もしそうじゃなかったら例えば 「文章段落は字下げをする」 ってスタイルも適用しにくくならないか?
文章に限らず、ある要素が、特にリストや他の要素にあたらないものならなんでもかんでも P 使うってのは、
なんでもかんでも DIV を使うのとどう違うんだろう。
たとえば、仕様に <object> を囲む要素は <container> 要素を使うとか
<button> を囲むときは <element> 要素を使うとかあったら <P> じゃなくそっちを使うわけでしょ。
自分としてはその役割が <P> じゃなく <DIV> だと思ってたわけなんだが。
>>166 <form> 直下にインライン置けないジャン。
>>167 あー、そこは意見が分かれるね。
段落の広義やら狭義やら独自解釈で「他に該当する要素がないからPにしているわけじゃない」と言い張るね。
あなたもヘンな人だから一緒に隔離されましょう。
divで括ったらおかしいやん <div><input 〜 /></div> はおかしいだろう <dt><label></label></dt> <dd><input 〜 /></dd> ならわかる。 あるいは <p><input 〜 /></p> やなあ。やっぱり。
隔離 orz まあヘンだとは自覚してるw > <div><input 〜 /></div> やるときは <div class="submit"><input type="submit" 〜 /> ・・・ </div> とかだろうけど 残念ながらこれがおかしいとは感じないんだよなあ。 名前付き input だったら dl とか ul とか使うけど、submit はリストにする必要性を感じないので、 「他に該当する要素がないから仕方ない」 と思っちゃう。
>>170 >>171 あら、おかしいと思うのオレだけ?
<div class="submit"><p><input type="submit" 〜 /></p></div>
ならわかるんだけどねえ…
DIV厨の次はP厨がトレンドか。 だから、本当のstrictだか偽物だかしらんが、 1)どこの団体が出したSpec.に書いてあるんだか、出典を示せ。W3CなのかISOなのか、俺様脳内定義なのか 2)俺様定義なら、昔のフラット論争の時くらいの、DTD自作して配るくらいの気概はないのか ないなら、そもそもそんなドメイン特有の用途には独自のスキーマで定義するしかない。この板の住人が使う程度なら、DocBookやらで十分だろうが。あるいはHTMLにこだわるにしても、microformatsなりDublin Coreで用が足せるだろ。 formだけは話が違うかも知れないが。
p厨ってw 不適切でないものとしてpは妥当だろう
divに必ずpやらブロック要素を入れたがる人を言ってるんじゃない?
P厨か。新しいな。
pでも食ってろdiv
>>172 DIVはコンテナだと思い込んでる人がやりそう。
>>172 ><div class="submit"><p><input type="submit" 〜 /></p></div>
これなら、
<p class="submit"><input type="submit" 〜 /></p>
が、正しい記述。
>>179 いや、そうでしょ
それを
<div class="submit"><input type="submit" 〜 /></div>
とかいうから <div 〜><p>〜 にしたまでだよ
個人的には ◎ <div class="submit"><input type="submit" 〜 /></div> ○ <p class="submit"><input type="submit" 〜 /></p> × <div class="submit"><p><input type="submit" 〜 /></p></div>
それだとさ、君は ◎ <div class="submit"><a href="〜">〜</a></div> ○ <p class="submit"><a href="〜">〜</a></p> ってことかい? div直下のインライン(またはインラインブロック)要素に拒否反応起こすんだが…
そんなのは <a> の内容によるし、一緒に考えるのはおかしい。 まあ、だいたいリンクのみのときはULリストになると思うのだが。文章の中に書くなら P だし。 そんなことわかってるでしょう?
p使うならdivは要らないってだけで、 div使ってる所にp使うのはおかしいだろって話でしょw
> div使ってる所にp使うのはおかしい div使ってる所にさらにp使うのはおかしい でおk?
>>187 根拠は?DIVは汎用ブロック要素であってコンテナじゃないよ。
根拠はないけど入れなきゃダメ
なにこの意地の張り合い。
>そんなのは <a> の内容によるし、一緒に考えるのはおかしい。 いや aじゃなくてもまあいいんだが とにかくdivで囲うんなら必要ないだろうって話 <input 〜 /> だけでもいいんでしょ そういう人は。 意味もたないdivで囲う意味がないやん
>>188 > 各々、内容が行内であるか(SPAN)ブロックレベルであるか(DIV)は定めるが、他のプレゼンテーション的語彙を示すことはない。
日本語と英語が理解できれば、その解釈はしないはずなのだが。
だいたいなんのために DIV は %flow になってると?
行内はインラインの中の 「行内」 に使えるだけでしょ。
>>191 その理論でいくとどこにもDIV使う意味がないよね。っていうかいらないよね。
現在のHTMLにある数少ない要素で全てがマークアップできると思うほうがどうかしてるよ。
それだったらダブリン・コアなんていらなかったでしょ。
相当する要素がないと思ってるから DIV 使うしかしょうがないんだよ。
無理矢理「相当する要素がない」と思おうとしているようにしかみえん。
>>193 >その理論でいくとどこにもDIV使う意味がないよね。っていうかいらないよね。
まったくその通り
勘違いしてると思われ
前にもでたが、divは何の意味もないんだって
何の意味もないわけではないと思うが、 使わないで済むのなら極力使わないほうがいいな。 div直下にインラインとか論外。 でもmap内にulのナビゲーションは map自体はインライン要素だから何かブロック要素に入れなきゃならないけど、 これを入れるコンテナがdivしか思い付かない・・・・ 他に何か考えつく識者、おられるか。
論争見て、 ddの中に必ずpを記述してる人を思い出した。
いや、 <div><p>〜</p></div> っていうのは皮肉だろう div要素直下のinputインラインブロック要素に対してのな
>>196 mapなんて使うか???
いらないと思うんだが
>>196 つか map要素って
area要素を包括しない場合には ブロックレベル要素 だろ
divで括る必要ないやん
map要素と言えば、クリッカブルマップでもないのに、 <map id="Navigation"> <ul> <li><a href="〜">〜</a></li> <li><a href="〜">〜</a></li> <li><a href="〜">〜</a></li> <li><a href="〜">〜</a></li> </ul> </map> とかやってるやつもたまにいるな おまえ、それ、普通のリストでいいやん って思う
>>192 その文章を根拠にdiv=コンテナって判断してるの?
だとすると併記されているspanについてはどう判断しているの?
それから
ttp://www.w3.org/TR/html401/struct/global.html#h-7.5.4 > The DIV and SPAN elements, in conjunction with the id and class attributes,
> offer a generic mechanism for adding structure to documents.
この文をどう解釈しているの?
id・class属性と共に、のくだり。
DIV要素に必ず一つ以上のブロック要素を含めないと気がすまないって人は (%flow;)* について説明してください
>div直下にインラインとか論外。 え???
>div直下にインラインとか論外 自作DTDですか? てーかけっこーそーゆーひと多いんかねw なんか最近のレス見てたら半々な気がして怖い。 重複してるんだろうけど……。
自分でそういうルールを作るのはいいけど 押し付けようとするのはやむぇとぇ
このIDのない板でその手の俺理論を主張する奴は 何度もしつこく主張する傾向があるので、 その状況下で常識的な見解と半々ということは、 このスレに常識が十分残ってるということだから、 喜ばしいことだと思うよ。 しかし、こういう一般的ではないスレは専門性の高さとは 違う部分で一般的ではない人も何か勘違いして紛れ込むから、 どう解釈してもおかしい人っていう人が湧きやすいのはしょうがない。
間違えた 論外につっこんでるのか 論外でしょう 文法があってればいいと言うんなら <bodY> <div><a id="top" name="top"></a></div> <div>なんたら<span style="font-weight: bold;">かんたら</span</div> </body> とかもなんでもありになっちゃうからね 極端な話
たぶん
>>209 のどこがいけないの?
っていうヤツがいっぱい紛れ込んでいるんだな・・・
レベル落ちたな・・・
>>209 どの書き込みが「間違えた」なんですか
レス番を名前欄などに書いてください
>>210 すまん 勘違い
プロでもdiv直下のインライン要素うやってるやつ多い
そして、それやってるやつは body直下のインライン要素というミスも
8割方やっちゃってる
だから
>>209 は
>>203 にある
DIV - - (%flow;)*
をどう解釈しているのか説明して
>>214 だからさあ
文法があってればいいと言うんなら
<body>
<div><a id="top" name="top"></a></div>
<div>なんたら<span style="font-weight: bold;">かんたら</span></div>
</body>
でもいいことになる
おかしいと思わないならいいんじゃないか
>>213 bodyは
O O (%block;|SCRIPT)+ +(INS|DEL)
だから「body直下のインライン要素」はだめだけど、
今はsんなことをやっている人を例に持ち出されても。
divは
- - (%flow;)*
だよ?
>>215 を参照
文法だけ合ってればいいっていってるんなら
ほんとにレベルが落ちたんだな
としか言えない…
>>215 も当たり前なんだろうな
>>215 >>202 を見れ
divやspanはid属性やclass属性をつけて著者が意味づけをする。
コンテナとして意味づけをするならブロック要素を包括するのが望ましいが
それ以外の意味づけをした場合は他のブロックレベルの文書構造要素(pなど)
と同等の振る舞いをする
>>218 流れに合わせると
<bodY>
<div class="anchor"><a id="top" name="top"></a></div>
<div class="intro">なんたら<span class="attention">かんたら</span></div>
</body>
こんなとこか?
なら<div class="section">〜</div>とかもあり、っていうことになるんだろうな
id, class付ければいい、ってやつはdiv/spanだけで足りると思うんだが
<a id="top" name="top"></a> を カウンター に置き換えてみるテスト。 つまり <body> <div>10010</div> </body> これはダメで <body> <p>10010</p> </body> これはイイ、っていうのでしょ? それがわからない。 明らかに P の中がそれだけ見れば 「ただの意味のない数字でしかない」 のに、 それを P で済ますのと、DIV で済ますのとどう違うのだ? P って文章やテキストが入った段落を示すものでしょう? ただの数字もテキストと言えようが、それでよしとするなら、P の意味が希薄にならないか? 私はもっと P の意味を尊重したい。 だから <div id="counter">10010</div> で使うしかないと思ってる。
> id, class付ければいい、ってやつはdiv/spanだけで足りる あなたは阿呆か? 既にある要素を使わないでどうする。 RSSだって、既存の要素で済めばそれが一番だけど、ない場合は仕方なくダブリン・コアなどのモジュールを使う。 HTMLではそれが簡単にできないから仕方なく DIV に id/class を付けて使うんじゃないか。
>>202 HTML 4.01の話なんだな
ならいいんじゃないのか…勧告自体がボロボロだしな…
>>220 <a id="top" name="top"></a>
はのa要素はさ、XHTMLじゃやるやつはいないとは思うが
まるっきり意味がない
カウンターとはだからちょっと違うと思われ
カウンターなら、
<body>
<ul id="counter">
<li>10010</li>
<li>00540</li>
<li>00010</li>
</ul>
</body>
とかでいんじゃないの
キャプションつけたいなら dlって手もある
既存の要素では望ましい構造やプレゼンテーション効果が得られない(適していない)ため div+classでサイト制作者が適切な意味付けをしてその効果を得るんであって、 コンテナとしての意味付けをしたならそういった振る舞いをしてもいいけど コンテナとしてしか使えないと理解してしまうのはどうかと。 自サイト内でそういう使い方しかしないようにするのは別に構わないけどさあ。
>>222 極端な例だけどね それはね
もともとはさ p要素でもいいと思われるものを
divで囲ってるところからそもそも始まってる
p要素だと言えない理由がないからね
じゃあdiv要素よりはp要素の方が適切だろう
って話
<p><a id="top" name="top"></a></p> はよくて <div class="nantoka"><a id="top" name="top"></a></div> がダメな理由がわからない。 むしろリンクだけのテキストを P に含ますほうが気持ち悪いと感じるんだけどw もしそうなら、 <ul> <li><p><a href="">home</a></p></li> <li><p><a href="">text</a></p></li> <li><p><a href="">link</a></p></li> </ul> とかもおかしく感じないんだろうね?
>>224 自サイト内でやるのはいいと思うよ
そもそもこの話も好みもある話だしな
押しつけてるわけでもない
どういう理由でそうするのかって話
そっちがよければオレもそっちを採用するw
>既存の要素では望ましい構造やプレゼンテーション効果が得られない(適していない)ため
ただプレゼン云々はHTML・XHTMLの範疇じゃないでしょ
>>223 > HTML 4.01の話なんだな
じゃああなたはDIVについてどのバージョンの勧告を読んでるの?その箇所のリンクを示して。
>>226 極端な例。
XHTMLなら
<a id="top" name="top"></a>
なんて使わないっしょ。
リンクじゃないしな よく見れ
後者のリストも中身によってはあり
でさ そもそもが p か div かどっちで括ろうかな
っていう内容についての話だったわけでしょ
p でだめな理由がなければ、divよりは適切なp要素にするのは当たり前
釣りだろw 試されてるんだよw 流せよwww
なんかかみ合ってないようだが p じゃないという理由があれば div でいいんじゃないの 今回の話はそういうことじゃない そこをなんかごっちゃにしてるからかみ合わない p でもいいかもしれないと思われるものを、div で括っちゃってるから それなら p でいいだろう って話なんだ
何を試しているのかわからん 自分がバカかどうか試しているのか
>>232 > p でもいいかもしれないと思われるものを、div で括っちゃってるから
> それなら p でいいだろう って話なんだ
そっちこそ、今回の話はそういうことじゃない、じゃない?
pや各種リストでいいものでも全てdivでするのは論外、ってのは共通の前提じゃないの?
お互いに違う論点を取り上げて話をしていたから話がかみ合っていなかった、 でFA?
>>234 どっから読んでるかわからんのだが
そもそもはさ
<input type="submit" 〜 />
をなにで囲むか、って話だったの
p要素でだめな理由があるんなら オレもdiv要素でいいと思う
ただオレはp要素がダメとは言えないんじゃないかなって思ったわけ
>>217 > 文法だけ合ってればいいっていってるんなら
文法より厳しい制約にすれば正しいってもんでもないんだよ。
不要に厳しい制約もまた間違い。
「文法で許されているものはすべて正しい」んじゃなくて、
「文法で許されていないことを制約するんだから、ちゃんと理由を言いましょう」
という話だな。
body直下にインライン要素をおくことを隠蔽するためだけに
divを濫用するアホがいくらうざいからって、その反動でdiv直下の
インライン要素をなんでもかんでも禁止してしまおうと思うのは、
過剰反応か怠慢だよ。ちゃんと場合に応じて判断しましょう。
禁止すべき理由を考えずに「なんでもかんでも禁止すりゃいいや」
ってのは同レベルのアホだよ。
>>220 というか、p要素にすればいい、というのは>209が叩くような
「形式的に文法だけ守っていればよい」という発想だな。
その文法がW3Cルールから脳内ルールに替わっただけ。
それが、>172みたいに「とりあえず段落でもないのに無理やり
p要素だということにしてしまえばOK」という発想につながる。
div要素は、class属性を指定しようがしまいがp要素の「段落」
という意味のような意味付けはできない。しかし、当然まったく
意味がないわけではなく、構造を付加することが出来るというのは
仕様で明記されてることだな。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.4 > DIV要素とSPAN要素は、id属性及び class属性と併用することで、
> 文書に構造を付加するための一般機構を提供する。
>>229 おまえがよく見れw わざわざコピペしてやったのに。だいたいそういう話じゃないだろw
> divよりは適切なp要素にするのは当たり前
何をもって 「適切」 としてるんだ?
DIV はコンテナだから、なんて話はお断りね。
>>236 をul/liで囲む俺が登場
したら話がややこしくなる?
>>238 p要素でないと言える理由がないから
別に理由があるならオレはどっちでもいいんだ
なんか知らんが勝手にかみつくなよ
>>239 既出
それでいい場合もあると結論がでてる
241 :
239 :2006/10/08(日) 10:20:47 ID:???
各入力欄を定義リストでやってんだから 送信ボタンもリストでいいじゃん
>>237 ほどほどいい具合にまとめてくれてると思う
ほんとにあまりわかってない人と
そこそこわかっている人の話だからかみ合ってない
お、おれも
>>237 みたいなことを言いたかったんだよ!
>>241 読むのがめんどくさいんだろうw
定義リストでもいいんだ
で、この場合のはさ、
<form 〜>
<fieldset>
<legend>〜</legend>
<dl class="input">
<dt><label 〜>ラベル</label></dt>
<dd><input type="text" 〜 /></dd>
<dt><label 〜>ラベル</label></dt>
<dd><input type="text" 〜 /></dd>
</dl>
<p class="submit"> ←ここな
<input type="hidden" 〜 />
<input type="submit" 〜 />
</p>
</fieldset>
</form>
じゃだめなの?って話
>>236 うん、
だから P はテキストを入れるものだから <input> を入れるのはおかしい、って意見。
P は仕様書のどこにあるかっていうと、「テキスト」 の項目にあるわけ。
「テキスト」 の項には 「フレーズ要素: EM、STRONG、DFN, CODE、SAMP、KBD、VAR」 とかの各種インライン要素、
「BLOCKQUOTE要素とQ要素」 などの引用文、
あと 「上つきと下つき: SUB要素とSUP要素 」 と、「段落 P 」 だけ。
ここから見てわかるように、P は本来 「テキスト」 つまり 「文」 をマークアップするものなんだよ。
「文」 以外になんでも入れていいものなら、「HTML文書の全体構造」 の項に P をいれればよかった。
わざわざそこにいれるってことは、「文」 を入れるものだという前提なわけでしょ。
だから 「<input> は文だ」 と言わない限り、P でいれるのはおかしいと感じるわけ。
「送信」とか書かれたボタンが一個転がっているだけなのにpは変。 順不同リスト一択
心の中ではずっと237と同じことを主張していたんだ!ただうまく表現ができないだけなんだ・・・
>>245 >だから P はテキストを入れるものだから <input> を入れるのはおかしい、って意見。
それ言っちゃうとさ
単体の画像なんかはすべて div直下にいれないといけない
そうやってやってるの?
まあinputとかが特殊なのはわかるんだけどさ
画像も順不同リスト
リストにボタン入れるのはもちろんOK。 だって リストの意味は 「リスト」 でしかないから、ボタンのリストは何らヘンじゃない。 でも、もしそれで DIV に入れるのは変、というのになったら、それはそれでおかしい。 それだと 「入れる要素がないからとりあえずリストに入れておきますね」 って考え方でしかないように思う。
>単体画像 ulはli+ つまり一個以上のli。一個であってもよい。
>>240 > p要素でないと言える理由がないから
そもそも、p要素であると言える理由が出てないんだ。
「文章の段落ではない」と言うが、それはどこのソースに
よるのかさっぱり不明のまま。
p要素が「9.Text」の項にあるのを見ても、仕様上では
段落という言葉がテキストを主とした普通の意味の段落を
意図して使われているだろうということは容易に分かる。
>>249 俺はそうやってる、ときもある。
<img> は <object> (や <applet> や <iframe>) なんかと同じ。
もし <iframe> を P で囲うのをおかしいと感じるなら、それは DIV で囲うしかないわけで、
そうなら、単体の IMG を DIV で囲ってもおかしいことはない。
もちろん、P の中でも <img> がでてきたらそれでいいと思うし、リストで使うこともあるし、それはそれ、これはこれ。
>>253 テキストしかだめっていうなら
<p><img 〜>の画像はアイコンです</p>
もおかしいということになるよ
実際にはテキスト以外も入るし それはしょうがない
>>254 まあそうだよね
それが不明だからどうとでもとれる
テキストの項にあるのは分類上の一言で片付けられる
>>243 ,,247,248
こういう自演をすると途端に説得力が無くなるからやめたほうがいい。
自演でなくても同じことだが。
>>256 ならばinputがダメな理由はないでしょ?
iframeとかは代替手段がないからどうかと思うけどね
inputのボタンなんかは一応代替手段がある
>>249 > 単体の画像なんかはすべて div直下にいれないといけない
本当に画像がHTMLのように段落中に表示されている文章を
読んだことがないのか?よくあるぞ。
じゃあなんでformの例にさんざんpが使われてるんだよw 都合の良いとこだけ仕様書からひっぱるなよw
>>258 >
>>243 ,,247,248
> こういう自演をすると途端に説得力が無くなるからやめたほうがいい。
> 自演でなくても同じことだが。
と思わせるためのアンチの仕業でしょ
>>262 わかってないなら書き込まないように
まずよく嫁
frameはstrictではない
>>259 全然わかってないw
話の流れで
<p>これをみてください!</p>
<p><img src="" alt="" /></p>
<p>なんとかかんとか!</p>
ってときもあるだろう。
これらは 「一連の文章」 の中に画像が包括されてるわけ。
<p>このボタンを押してね → <input /></p>
ってこともあるでしょう。(まあやらないけど)
それらの場合はいいんじゃないの?
なんでもかんでも決められないとわからない子なんですか?
それはそれ、これはこれ、って言ったでしょう。
「単体の画像」 とか特殊な状態をいってたのに、 その前提条件で交わした意見を全ての場面で持ち出すからわけわからなくなる。
>>266 「一連の文章」ってことなら
<input 〜 />をpで括っても「一連の流れ」で済む
だめな理由にならないじゃない
ていうか、「一連の文章」だから、っていうのもちょっと違和感あるなあ
>>266 > <p>これをみてください!</p>
> <p><img src="" alt="" /></p>
> <p>なんとかかんとか!</p>
一連の文章なら
<p>これをみてください!<img src="" alt="" />なんとかかんとか!</p>
とすべきじゃない?
上の段落と下の段落に画像が置かれているのなら画像はul/liで
>>261 だから段落中に画像が出てくる文章を読んだことがないのか、と。
インライン画像が入ってる段落ってのは普通にあるわけで、
「画像が入っても段落なら、inputが入っても段落だ」なんて
成り立たんのよ。
>>257 > テキストの項にあるのは分類上の一言で片付けられる
分類は意味でなされてるんですが。段落という言葉に、
input要素をp要素のなかに含める派が主張するような
特段の意味がどこにあるのか明示されないかぎり、
>168の言う
> 段落の広義やら狭義やら独自解釈で
> 「他に該当する要素がないからPにしているわけじゃない」と言い張るね。
というような解釈は単なる屁理屈で筋が通りません。
(言葉の定義をいくらでも変えていいなら、仕様なんて
あってないようなものになってしまうからね。)
>>269 そう、その違和感があった
代弁サンキュー
でも
>>266 も悪いとはオレは思わない
だから、なんで input の場合はだめなんだ?って話
>>262 仕様書の例は必ずしも strict じゃないのは、あなたやみんなも知っていることでしょう。
仕様書の例が strict だと言うなら、いろいろな場面においてここの議論とはかみ合わないと思うのだがどうか?
だからといって、仕様書のDTDや説明はおかしくない、という立場なんだが。 おかしいかな?
テキストの項目だからテキスト用w pの意味を大切にしたいからこそdiv w ロマンチストか!
別にdivに過剰反応してるわけでもないんだけど "現状"ではpでダメな理由がない むしろいきなりdivの方が変だなって思っちゃう
>>269 「例」 だってばw 短くしただけなんだから。
まあ誤解を生みそうだったのは謝る。
もちろんその前後にP段落は他にもあるだろうし、文章も長短あるだろうし、いろんな場合があると思うよ。
>>271 サブミットボタンの前後に意味がつながるような文章を置くのなら
まとめてpでくくってもいいと思うよ
そんな場面が思いつかないけど
そんな小さい囲みにdiv使ってたら自己矛盾だらけで禿げるぞw 文書全体で考えろよな。
>>276 ボタン自体にもテキストが設定されている
まあリストでいいと思うんだよ
type="hidden" がなければね
pで全部括るのもありだと思う
でさ、
<p class="submit">
<inpu type="hidden" />
<inpu type="submit" value="データを送信します" />
</p>
がなんでdivにしなくてはいけないのか、ってことでしょう
テキストいれるとわかりやすい。
>>277 じゃあ文章がなくフォームしかない文書の全体ではどうなの?
>>271 > だから、なんで input の場合はだめなんだ?って話
話は段落中のinputじゃなくて、フォーム中のinputを指して言われていて、
それをdivで括るのはおかしいがpで括るならいいと言う>169あたりの
主張がおかしいわけだ。
> <p>このボタンを押してね → <input /></p>
> ってこともあるでしょう。(まあやらないけど)
こういう例ならありうるだろうな。今回の話とは違うけど。
>>279 フォームしかなくても、
注意書きやラベルがあるだろう
まさかボタンだけのフォームなんて使わないだろう?
>>280 >話は段落中のinputじゃなくて、フォーム中のinputを指して言われていて、
>それをdivで括るのはおかしいがpで括るならいいと言う>169あたりの
>主張がおかしいわけだ。
じゃあ、dl等のリストもおかしいよ
リストからのつながりで p があるわけ
確実にだめな理由がない
>>277 なんでもp要素にするやつが禿げないのは、
自己矛盾がないからではなくて、
自己矛盾がどうでもいいからです。
submitおよびhiddenはli! <form> <dl> <dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd> <dt><label for="hoge2">ほげ2</label></dt><dd><input id="hoge2" /></dd> <dt><label for="hoge3">ほげ3</label></dt><dd><input id="hoge3" /></dd> </dl> <ul> <li><input type="hidden" /><input type="submit" /></li> </ul> </form> うまくまとまってね・・・?
>>285 いや、それでもおれはいいと思うよ
divにしなくてもそれでもいいのよ
で、なんでdivにする必要があるの?ってこと
おれはpの方がいいかなって思うからpの方にしてるだけ
>>285 hiddenは値を表示しないとはいえ項目のひとつなわけで、
それを他の入力項目と異なる、投稿承認ボタンに含めるのは
まとめかたがおかしいだろ。
>>285 だから リストにするのはもちろんいいんだけどね。
でもその理由が 「入れる要素がないからとりあえずリストに入れておきますね」 ってのじゃ、
DIV に input を入れるのは否定できないよ?
pがだめとなると
>>285 もだめということになるな
div派はやっぱり無理があるかもね
>>280 Pはテキストの項目にあって一目瞭然なんだから、認めちゃダメだよ。
Pの場合もあるなんて。
いかなる時も例外なく認めるなw
>>289 入れる要素がないから
ではないでしょう
divこそが入れる要素がないから入れておきますね
でしょう
>>290 駄目で何が困るんだろう。
p派はそもそも段落じゃないものを段落扱いしている
仕様違反だから論外なわけで、リストなりdivなり
他の手段を採らないといけないのは明らかなんだが。
>>293 段落じゃない理由がない
定義がないんだからさ
submit(やhidden?)をdivに入れている人はidかclassの属性値に何て振ってますか?
>>291 DIV派だけどそれはちょっとw
>>290 違う、問題は DIV の扱いじゃなくて、P の扱いなんだよね。
>>292 うん、最初から言ってるけど、他に入れる要素がないから DIV しかないの。
>>284 なんだもう禿げてるのか。すまなかったな。
submitはテキストじゃなくて属性値だよな。
>>291 で、お前は段落に画像が含まれる書籍を読んだことがないのか?
>>296 いや、入れる要素あるだろう
リストだってあり
なんか盛り上がってきたところで、
オレ的には
>>288 の意見がちょっと参考になった
つうか何人いるんだよ?
まとめるとだ、
<form>
<dl>
<dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd>
<dt><label for="hoge2">ほげ2</label></dt><dd><input id="hoge2" /></dd>
<dt><label for="hoge3">ほげ3</label></dt><dd><input id="hoge3" /></dd>
</dl>
<ul>
<li><input type="hidden" /></li>
<li><input type="submit" /></li>
</ul>
</form>
これがスマートそう?
それとも、hiddenのにもラベルふって <form> <dl> <dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd> <dt><label for="hoge2">ほげ2</label></dt><dd><input id="hoge2" /></dd> <dt><label for="hoge3">ほげ3</label></dt><dd><input id="hoge3" /></dd> <dt><label for="hidden">ほげ4</label></dt><dd><input type="hidden" 〜 /></dd> </dl> <ul> <li><input type="submit" /></li> </ul> </form> こうか? それともsubmitボタンまで全部ラベルふっちゃうか? それでもいいな
>>296 そらしゃあないわ。わからないんだからdiv。
div厨はそうだもの。
>>294 一般に「ボタンがならんでるだけ」を段落とは言わない。
で、もし一般にボタンの羅列を段落と言うと主張するなら、
こちらに悪魔の証明を要求しないで、主張する側が
ちゃんと「ボタンの羅列やボタン単体だけでも段落と
認められる理由がありますよ」ということを示さなきゃ。
でないと、言葉の定義をいくらでも変えていいなら、
仕様なんてあってないようなものになってしまうからね。
>>299 だから、それだと無限ループだろがw
「入れる要素がないから」 DIV なり UL なり使うしかない。
だって P はおかしいから。
単体なのに UL 使うのもおかしいというかその必要もない気がするから、DIV を使う。
もしボタンが何個も並んでるなら UL 使うしね。
一般と同じならだれでもStrict+erだ
>>302 <li><input type="hidden" /></li>
これがレンダリングの際に気になるんだけど仕方がないのかなあ。
liにスタイルシートでdisplay:none;すればいいか。
hiddenってスタイル的な印象があってhtmlにはそぐわない気がしてるんだけど
>>303 submitボタンにラベルを振ったらラベルの文字列を押しただけで送信されてしまって
>>306 だから、最終的に意見を取り入れてまとめた
別にオレはオレルールを押しつけるつもりもない
ここにはそういうやつ多いがなw
だから意見を取り込んで、
>>302 や
>>303 はどうかな?って言ってる?
これじゃだめだから、やはりdivにする必要があると思う?
>>308 >これがレンダリングの際に気になるんだけど仕方がないのかなあ。
>liにスタイルシートでdisplay:none;すればいいか。
そうすると、見た目的にもよくなるね
>submitボタンにラベルを振ったらラベルの文字列を押しただけで送信されてしまって
え?そうだっけ?
どっちみちアクセスキーを設定する場合とかもあるし、
これならいいかなって気がしてきた
P派はボタン何個も並んでるとき <p><input type="hidden"/> ・・・</p> ・・・ <p><input type="submit"/> ・・・</p> とかするの? <div class="hidden-elements"><input type="hidden"/> ・・・</div> ・・・ <div class="submit-elements"><input type="submit"/> ・・・</div> って書いたりするんだが。 submit の中に hidden系入れることもあるけど、submit はひとつとは限らないし。
以前、submitを含め全てを定義リストでやってたけど
submitに文字列があるのにlabel側にも同じようなことを書いてて
なんだかなーって思ってやめた
そして今は難民。
>>302-303 みたいにもっと使えそうな案を出してください
>>309 あなたがそれでいいなら、いいんじゃないかな??
とくに反対する理由もないよ。
DIVにする必要がある、なんて言ってないし。
方法のひとつだとは言ってるし、P はおかしい、って言ってるけど。
>>302 <form>
<dl>
<dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd>
<dt><label for="hoge2">ほげ2</label></dt><dd><input id="hoge2" /></dd>
<dt><label for="hoge3">ほげ3</label></dt><dd><input id="hoge3" /></dd>
</dl>
<div><input type="hidden" /></div>
<div><input type="submit" /></div>
</form>
なんだが(divには適宜class指定するとして。)、
もしhiddenとする項目が複数ありうるものなら他の項目と同様にリストに
なると思う。その場合はdivより適切な要素があるから、divを使ったら濫用だろう。
同様のことはsubmitにも言えて、リストとして値を設定または保持するようなinputではなく、
フォームの使途の意思決定を意味するようなinputのリストになりうるものならばリスト
を意味する要素とするべきで、divを使うべきじゃないだろう。
意図による。俺は>302が不適切なグループ分けだと思っているが、
もし
> <ul>
> <li><input type="hidden" /></li>
> <li><input type="submit" /></li>
> </ul>
とする理由があれば、それが仕様に反しないならそのマークアップもOKだと思う。
だからどういう意図でリストに含めているのかききたいな。
>>311 そうしてる
>>312 >submitに文字列があるのにlabel側にも同じようなことを書いてて
そうだね。んだから、
>>311 みたいにすることもあったんだわ。
最初の質問を受けて、ここまでp派でやり出した本人はオレだが
pでダメな理由にはまだ納得はしていないんだ
でも、意見を反映して
>>302-303 みたいにまとめてみた
divも別に否定はしないけど、pがあやしいっていうヤツもいるわけだし、
今はこれもいいかな、って思ってる
でも、マークアップとスタイル指定が面倒だなw しゃーないか
>>307 一般から外れればなんでもStrictと言うわけでもないよ。
それはただの勘違いさんだな。一般にもダメで、Strict的にも
ダメという、救いようのない脳内ルールの持ち主。
>>314 それもそうだな、と思ったわけで、
最終的には、これどう? って感じなんだが
<form>
<dl>
<dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd>
<dt><label for="hoge2">ほげ2</label></dt><dd><input id="hoge2" /></dd>
<dt><label for="hoge3">ほげ3</label></dt><dd><input id="hoge3" /></dd>
<dt><label for="hidden">ほげ4</label></dt><dd><input type="hidden" 〜 /></dd>
<dt><label for="submit">送信</label></dt><dd><input type="submit" 〜 /></dd>
</dl>
</form>
tableでした場合も、 <tr><th><label>フォームコントロールの役割</label></th><td>フォームコントロール</td></tr> ってしてもtype="submit"やtype="hidden"はあぶれてくるね
誰かが 「DIV はコンテナ」 といってたけど、自分もそう思ってたのに気づいた。 ただし、その人が言う 「ブロック要素しか含めないコンテナ」 ではなく、 「インラインもブロックも含められる (%flow) コンテナ」 だと思ってる。 だから、 <div class="nantoka"> <input type="hidden" /> <input type="hidden" /> <input type="hidden" /> </div> とかやるし。
>>288 の意見を取り入れるとそれはないなあ
たしかにhiddenだけでまとめるのもなんか違うな
つか、form要素が無くなってきりかわるまできついな ほんと
>>317 hiddenのラベルに何を書くの?それは閲覧者に知らせないといけないもの?
submitはvalue属性値とlabelの文字列とが重複して冗長になってしまわない?
という疑問が生まれます
>>317 それはアリだと思う。フォーム部品としてすべてリストしてるわけだな。
ただ、この話は
> <dt><label for="hidden">ほげ4</label></dt><dd><input type="hidden" 〜 /></dd>
> <dt><label for="submit">送信</label></dt><dd><input type="submit" 〜 /></dd>
の「ほげ4」や「送信」のように、他の入力項目の内容説明と同様の説明は
付けないもののマークアップの問題じゃなかったんだろうか。
「マークアップのための原文改変(=意図変更)」をするんじゃない限り、
そもそも説明を付さないつもりだったんなら、その例だと解決できない。
317で意図どおりの文章なら別に問題ないと思うよ。
>>323 閲覧者に知らせなくてもいいものでも、いいと思うけど
submitは、kbd要素とかと合わせてラベルを付ければいいんじゃないかな
>>317 だと余計な部分をスタイルシートで非表示にさせるために
各dt/ddに個別にidかclassを振らないといけなくなるからなあ
デザインを考慮するがために構造に制約をかけるのは間違っているんだけど
やっぱり面倒くさい・・・
>>324 そもそも内容説明がないことが問題なんだから、説明くっつけるのはいいんじゃないかな
見た目はCSSで変えればいい
ただhiddenはいいけど、たしかにsubmitはちょっときになるな・・・
<dt><label for="submit"><kbd>S</kbd></label></dt><dd><input type="submit" 〜 /></dd>
じゃだめかな?
labelの使い方がちと問題な気もするが w
構造的には
>>317 の反応悪くないね
p使ってたがオレもこれにするかな
つか でもほんとに面倒くさいね しゃーない
そもそも、ブロック要素の中に<input type="hidden" />だけを入れるのはいいの? それはマークアップの為のマークアップになるんだけど。
submitだけ中身を逆転させて、 <dt><input type="submit" /></dt><dd><label>記入内容が送信されます。</label></dd> とかは?
>>330 それってあり?
まあありか ちょい気持ち悪いけどw
とりあえず定義リストでまとめるのが無難そうだね
面倒だけど
333 :
330 :2006/10/08(日) 11:41:11 ID:???
やっぱり気持ち悪いかあ 自分でも気持ち悪い
>>329 現状ではいいに決まってる としか言えない
formが悪いだよな ほんと
formが悪いのには同意だけど、やっぱ良いってのはおかしいと思うんだよなぁ。 デザインの為のマークアップとどう違うんだって。 他にどうしようもないから使われてるだけで、本来良いとは言えないだろって感じで。
ってか根本的解決になってないよw
P はどうした P はw
P じゃおかしいってことを理解して、
代案として模索するうちに DIV はどうしても気に入らないから
>>317 にする、にいたったわけなのかな?
意味の持ちようもない hidden くらい form 直下、fieldset 直下に置けたらありがたいのだけどね。
本音をぶっちゃけると、
>>317 も気持ち悪かったりw
>>327 > そもそも内容説明がないことが問題なんだから、
マークアップ上の問題であって意味上の問題じゃなくないか?
マークアップの問題はマークアップで解決した方がいいと思うんだが。
「当てはまる要素がない」なら、「divを使う」というように。
もし内容説明がないことが原文の問題だと思って説明を加えたなら、
表示はCSSなりに任せりゃいいと思うよ。そのCSSでの表示とかは
HTMLとしては関係ないんだし。
>>336 おかしいとは納得してない
特に
>>330 のような場合は p が良いと言える
divは気に入らないのじゃなくて、それもありだと言ってる
で、妥協も含めてもっとも適切そうなのが
>>317 という結論
>>339 それいったらラベルも必要なくなる
そもそもhidden自体も悪いよな
submitだけはたしかに、オレも微妙だと思うんだけどね
>>336 個人的には、pが違和感ありまくり。
それならまだdivの方がいいけど、divにも違和感有りなので
もっといい方法があればいいのにって感じだな。
ただ
>>317 も比較でマシなだけでなんか気持ち悪いw
>>341 に補足。
違和感があるけど、pもdivもダメな訳ではないとは考えてる。
まあオレも含め、
p派もdiv派も
>>317 ならまあいいかな
って感じか
もともとは誰かの質問だったんだが、
オレもいい方法があればと思って書いてた
まあhiddenとか必要な作りにするほうがダメってこと
っていうとまた反発されるかな?w
>>317 よりだったら UL のがマシかなあ、って思ってるひとはいない?
>>335 > 他にどうしようもないから使われてるだけで、本来良いとは言えないだろって感じで。
いや、仕様に書いてあるって。構造を付与するのには一般的にはdivとかspanを使えって。
本来の使い方だよ。
不必要な局面で使う(つまり濫用する)のはStrict的によろしくないけど、
本来使う局面でも拒絶反応を起こしてより不適切な方法を採るのはよろしくない。
ただ、本来の文章の意図を損なわずマークアップする他の適切な方法が
あるならそれを使うべきで(そんじゃないと「全部divとspanでいい」なんてことになる)、
他の方法を検討してみるのはまっとうなことだな。
hiddenは必要でしょw セッションデータを見えるように表示させたら混乱を招くし、 クッキー使うとしたらバグやクロスサイトスクリプティングとかで悪用される可能性もある。 反発以前に流石にそれはありえないぞwww もちっと勉強して恋w
>>350 見映えは関係ない
おまけにそういうのが必要ない作りにすればいいだけ
もちっと勉強するのはどっちだか・・・
ま、現状難しいからこういう議論になるわけ
>>340 > それいったらラベルも必要なくなる
いや、hiddenのとsubmitのにつけるラベルはいらんと言ってるんだが。
で、それはdtに含まれるものじゃないから別にする、という。
>>352 >hiddenは値を表示しないとはいえ項目のひとつなわけで、
が適切だとすれば、hiddenにラベルが付くのはおかしくない
submitはちょっと気持ち悪いのはたしか
つか、hiddenつかわないで、 全部、<input type="text" 〜 />にしてさ、 CSSで消しちゃえばいいんじゃね?w
hiddenを使わなくてもすむようなスクリプトを作れ・・・?スクリプトにまで言及っすか・・・
ねーよばかw
>>354 > が適切だとすれば、hiddenにラベルが付くのはおかしくない
うん。だからそれはそもそもの意図による。
入力を要求する項目は項目名ラベルをつけて、
入力を要求しない項目は項目名ラベルはつけない。
という意図ならhiddenにラベルはいらんし、
項目なんだから入力の要求の有無にかかわらず、
全部に項目名を記す。
という意図ならhiddenにラベルをつける。
ありだろ そもそも hidden なんておかしいしね
結論 ・全部 type="text" にする ・dl, dt label dd のセットにする ・本来 hidden のやつはCSSで消せ でFA?w でも、ありかもしれないなこれ あ、XSS問題あるか…?
>>358 デザインありきの構造は当然ダメだけど
ロジックありきの構造もダメだと思うけど
それだったら <dl class="hidden-elements"> <dt>mode</dt> <dd><input type="hidden" name="mode" value="new" /></dd> <dt>no</dt> <dd><input type="hidden" name="no" value="123" /></dd> ・・・ </dl> とかでいいやん。 わざわざ text とかにして CSS 切ったら入力できちゃうものにする必要なんか全然ない。
うn hiddenをtextに置き換えるなんて正気の沙汰とは
必要ない作りって現実的に考えて無理じゃね? 一体どんなのを想像してるんだろう。
>>363 いや、それは方法のひとつとしては認めるけど、
っていうか結論はないとおもうw
いくつか案でればいいかな、って思ってる。
hidden 自体がいらないもんだからね とりあえずはdl dt label dd で全部セットにするだけのがよさそうか はやくformなくなんねーかな・・・
>>357 157の基地外がいることを忘れるなよ。
かなり長期間、この板に限らず暴れてるのがいる。
CSS使えない環境は無視なの? 携帯とかw
>>367 必要ないのは無駄な脳内ルールだろ。
「divはなんか嫌だ」とか言わなければ、
濫用しないだけで話は終了。
>>371 それいったら Strict 無理やんw
157人の基地外がいるってこと?
>>157 が基地外ってこと?
アンカーミスじゃない?
>>372 必要ないからなくなるんだよ
現状ではしょうがないがな
hiddenなんてのはHTMLには相応しくはないな
>>372 だが、hidden要らないって言ってる奴が現実に居るからね。
ここに。
WebProg板の住人が聞いたらなんて反応するやらw
要らないというか なくていいもの って感じだろう WebProgrammerは糞みたいなHTML吐き出すの得意だからな・・・
hidden なしでどうやってやるんだよw セッション値とくらい hidden にいれさせろよwww クッキーにいれろとかアホいうなよ?
個人的には
>>317 が候補に挙がっているんだけど
スタイルシートとかは適用させない状態で
冗長にならないようなhiddenとsubmitのラベル
何かいいものありますか?
って素の状態だとhiddenのところは用語(dtとlabelの部分)だけが表示されるんかあ
>>374 ,375,376
>153の間違いです。>157はホントごめんね。
153はさすがにネタっしょ。名前からしても。ネタというか騙そうとしているか。
>>380 type="text"でもいい
そもそも今後 hidden はなくなるわけだしさ
>>381 さっき上げたけどアクセスキーとかは?
<dt><label for="〜"><kbd>S</kbd></label></dt>
他のヤツがなんもいわないからわからんけどw
>>378 > だが、hidden要らないって言ってる奴が現実に居るからね。
要らないという人間が出す代案が現実的じゃないんだから、
要らないってのが現実的じゃないんだろ。
現実的じゃないことを言う奴が現実にいることはよくあるけど、
せめて非現実的でもStrict的ならスレの範疇なのになあ。
で? いつからなくなるの?
hidden はtype="text"でいいね たしかに 構造と関係ないじゃん CSSで非表示はありだと思う 現状はちょっとむずかしいだろうけどね
type="text"って簡単に誰にでも改ざん去れちゃう時点でダメじゃない。
type=text にして css で隠してるんじゃ hidden とかわんねー、 っていうか css のきかない携帯ブラウザはどうするんですか。 IE6 が全然使われなくなるなら <button type="submit" value="nanka">submit</button> ができるからいけど。
>>389 だから逃避すんなってw
現在のHTMLについて考えなきゃ意味がない。
htmlだけで考えてるからこんなアホな思考回路になるんだよw hiddenもだけど、CSS未対応ブラウザを考慮してなかったりとかも、ありえなすぎる。 htmlの仕様を考えるとしたって、他の状況を考慮するぐらい当たり前なのに。
>>388 なんでこのスレでスタイルシートを適用することが前提なんすか
>>390 hiddenでも改竄されるけどな
>>391 それって
<b> と <span style="font-weight: bold;"> が同じ
といってるのと同じ
type="text"にするのはStrict的じゃないか
携帯とかははっきりいって、他のも問題あるからな
>>393 考慮しててもありだろう
見えて困るのは制作者側の都合
なんか問題を斜め上にとらえるひとがいます。
だから現実問題としては難しいな と始めからいってるわけだが? オレは例を出しまくってるわけだが 他のやつはかみつくだけだな それじゃ使えないよ
かみつくだけの能なしが多いのは同意
何このスピード?
よく伸びるな
>>393 おい
そんなこと言うとこのスレの存在自体が無意味だぞw
もう収束してるけどねー
hiddenで改ざんって、reffer取ってるところだとそれの偽装までしてやらないとダメだよな。 textだとCSSをOFFにして普通に書き換えて出来ちゃう。 CSS非対応の携帯だと普通に表示されてるから、間違えて書き換えてしまう可能性も有る。 製作者側の都合じゃなくて、ユーザ側で起きる問題への対処でもあるんだけどなぁ。 何も知らず知ったかの知識で言い訳してるからこういう矛盾に繋がる訳で。
>>404 textの方がたしかに簡単だけど
hiddenも簡単にできるんだけど
ま、普通のやつはやんないだろうけどね
問題はCSS未対応の環境とか
それがあるから難しいな、と最初から言ってる
途中で誰かが変なこと言うからこうなる
>>402 厳格なStrictである事≠CSS等の対応状況を考慮しない
問題把握してやるぶんにはいいんじゃない
type="text"もね
とりあえずは、 dl dt label ddでセットにするのがまあまあよさげか?
ってのがひとまずの収束でしょう
で、
>>201 はどうなのよ
あれ、オレも見たことある
おかしいよね
>>405 悪意を持ってやってる人が簡単かどうかではなく、
悪意も何もない無知な一般人が知らずにやってしまうかどうかが問題なんだよ。
だからその最初の段落の反論は意味が無い。
きつい言い方すると自己満足のための形だけの反論でしかない。
そういうレスを続けるからズレてくんだよ。
mapなんて使ったことないー
個人的な意見 hidden はある種の「機能」であって、文章構造の一部ではない。 だから他の input 要素と対等にマークアップする必要はない。 submit ボタンの手前に添えるくらいで問題ない。
mapの使い方を間違えてるというか、使いどころを間違えてるって感じだな。
そのmapの人はそっとしておいてあげればいいんじゃない? ここで取り上げる内容でもないかと
>>408 いや、だから問題として捉えてるわけ
それをかみつかれてもなあ
>>410 ちょっw
また再燃か?
でも大概hiddenって type="text"でもいいもんもあるよな
じゃあhiddenなんてどうでもいいもんはどうでもいいもんの中にいれたら? <form> <dl> <dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd> <dt><label for="hoge2">ほげ2</label></dt><dd><input id="hoge2" /></dd> <dt><label for="hoge3">ほげ3</label></dt><dd><input id="hoge3" /></dd> </dl> <ul> <li><input type="submit" /></li> </ul> <div class=""><input type="hidden"/><input type="hidden"/>・・・</div> </form>
<dt><label for="hoge3">ほげ3</label></dt> <dd><input type="hidden" /><input type="submit" id="hoge3" 〜 /></dd> とか dl dt dd はそのままでいいと思う
これだけ否定されてもtype="text"に拘る人が居るんだな 負けず嫌いと言うか
>>418 hidden のためにブロック要素をこしらえること自体に違和感を覚える
あと、無理にリストにせずにテーブルを使えばいいんじゃないかと思うんだが
>>417 textっていうか radio とか select でもいいのとかあるよね
modeとかはそう
>>419 用語(dt)=ラベル
が
定義(dd)の一部(type="submit")としか呼応していないって変じゃない?
>>423 dt要素はdd要素と対応してる
submitに対応しているのはlabel要素だから
問題ないと思うんだけどどうかな
>>425 ユーザが入力されたものが表示されるだけで、
レンダリングされるものじゃないから
テーブルもいいと思うけど。 <th><label for="hoge">ほげ</label></th><td><input id="hoge" /></td> <th><label for="hoge1">ほげ1</label></th><td><input id="hoge1" /></td> <th><label for="hoge2">ほげ2</label></th><td><input id="hoge2" /></td> ただ、結局tableにしてもhiddenとsubmitに関しては同じ問題にぶつかると思う
>>422 それだとユーザが変えちゃう場合もあるじゃない。
hiddenは通常の操作で勝手に弄れないようにって目的も有るでしょ。
>>429 そうだね、だけど見えててもラベルくっつけてさ
checked="checked"にして引き継げば問題ないことも多い
まあ勝手にいじられないようにってのはあるんだけど
とか色々考えると、やはり最初の
>>217 かって感じか
>>430 極論になるけど
<td><label for="〜">〜</label></td>
<td><span style="display: block;"></div></td>
と同じだと思う
inputにはレンダリングされるテキストがない
>>432 > <span style="display: block;"></div>
おちつけ
>>432 すまん
<td><label for="〜">〜</label></td>
<td><span id="〜" style="display: block;"></span></td>
の間違い
そうでなくても、どこが表?って思っちゃうんだけど
どうなんだろうね
>>アンカーの下に1行空行を空けてる奴は いくらなんでも必死杉だから少し落ち着いてはどうか
>>436 うん だからそれが最初のほうで出てた
けど現状では仕方ない
単純に表はどうなのって思っただけなんだけどね
hidden要らないって言ったりとか、渦中の発言してたのは一人なんだよな 普通の人なら一言レス貰えば納得できる事を、 これだけのレス費やしてやっとってどれだけやねん
>>428 テーブルは俺も実は違うと思ってる・・・
>>439 一言レスもらって終わりなら div で終わってたっしょ
dl なんて一つの方法論にはたどり着いてないと思う
俺には有益だった
dlは過去スレで何度も出てるけど。
>>443 hidden、submitを絡めたのは出てないんじゃないか?
>>441 すまん 混乱した
単純に表ではないと思っただけだ
th が dt td が dd に対応するからありなのか?
ただこれだと hidden の問題が解決できないね
ということで たぶん dl のほうが適切
type="text" の要素にDLはいいんだけどねえ。 button や hidden になるとねえ・・・。
hiddenもlabel付けるってことで収束 buttonこそdivかな
TABLEのひとはsubmitはどこに組み込むのかね。 一般フォームなら表でもいいけどね。 というか表のが適したフォームのときもあるしね。それは場合によりけり。
こういう過去の議論とか妥協案とかさ どっかにまとめないの?
tableにしろdlにしろsubmitとhiddenに無理が出る
いや、だからhiddenは無理でないって submitも微妙だがおかしくはない ってこと tableだときびしい
buttonて
>>451 どうマークアップするとおかしくないの?
そしてその方法はテーブルには適用できないの?
button は submit とか reset とかボタン系の総称な。 じゃあDIV派の俺はでかけてきます。 帰ってきたらひとつの結論でてるのかな・・・。 興味深い議論ありがとでした (。。
>>217 に出てるじゃん
tableだとセルで区切られちゃうので厳しい
ん?
面倒だからhiddenはheadの中に入れてしまえ。
>>458 <dt><label for="submit">送信</label></dt><dd><input type="submit" 〜 /></dd>
この部分がこれでいいのなら、これを
<tr>
<th><label for="submit">送信</label></th><td><input type="submit" 〜 /></td>
</tr>
と置き換えても別にいいんじゃないの?
>>457 どうやって入れるんだよ・・・w
buttonも
<dt><label for="〜">〜</label></dt>
<dd><button><img 〜 /></button></dd>
ならこれでいいと思う
<button><img 〜 /></button> はできないわw
>>460 それでもいいんかな?って聞きたいとこだが
hiddenは
<tr>
<th><label for="hoge">ほげ</label></th><td><input type="hidden" 〜 /></td>
<th><label for="submit">送信</label></th><td><input type="submit" 〜 /></td>
</tr>
とかか?
扱いづらい上に、セル非表示にした場合にIEでバグなかったっけ・・・
補足たのむ
これがブレインストーミングってやつですか すごいですね 人数が少ない感じもしますが
感動した!
>>410 レンダリングされないというHTML上での意味づけだと思うが。
当然レンダリングするように設定を変更しているユーザもいるので、
それにセキュリティを頼るのは完全に間違いだが、隠す意図を
HTML文書として表現することはHTMLとして意味があることだろう。
「他のinputと同様に項目だ」とみなすか、「他のinputと違って
入力を求めない項目だ」とみなすかは文書作成者の意図による。
基本的にはどちらも成り立つので、ホントに意図次第。
しかし、隠すという意図をHTMLで表現したいのにtextと指定するのは、
意図とマークアップが一致していない、仕様を無視したHTML文書だな。
そういう場合があるのにdivを無理に避けるからアホなことになるわけで、
現実的にはなんも難しいことはない。
>>398 は素直にdiv使えばいいだけ。
>>463 hiddenの</td>とsubmitの<th>の間に</tr><tr>がいると思う
>>467 他にレンダリングしない意図を持つ要素ってあったっけ?
まあformが特殊っちゃあそれまでだが
>>468 汲んでくれw
間違いだ
>>463 は問題あったらよろしく
うn
>>470 トンクス
じゃあtableでもいいわけね
ただhiddenを別セルにするのだけは困りそうだね
>>462 はおっけいっしょ?
なにこれw
>>462 は問題ないと思うぞ
ログ読んでくるわ
15分後に読む価値のないログを読んだ473が激昂する
途中いらんとこあったけど読む価値あったよ
ところでhiddenだからって上の要素をdisplay:noneにしちゃったら、 hiddenの値を送らなくならね?
なにこのアホアホカーニバル
俺の素朴な疑問が数日後にこんな議論に発展するとは思わんかった。
いや、input を P にいれなくなっただけ実はあったと思うw
type="hidden"を要らないと言わなくなったのも大きな前進だなw
なんでもかんでもP要素にする奴を指すP厨という言葉も出来たしな。
>>483 P厨乙
Strictスレが初心者スレ以下なのは昔から
hiddenを使わない場合、GETで値を渡すのが無難だと思うが、パスワードなどの値を渡すのには向いていないな。 ブラウザのアドレスバーで丸見えだし、アクセスログに記録されるし……。
>>488 WebProg板行ったら笑われるぞ
ま、hiddenの代用ならいくらでもあるが、だからといって無くさなくても
別にいいやな。
490 :
Name_Not_Found :2006/10/09(月) 00:26:19 ID:Op92HuIo
フォーム関連はXFormsで解決。
pでも食ってろdiv。
getじゃ文字量も決まってるのがきついな。
SSのアドレス欄でIDとかパスワードが漏れた例も実際に有った気がするw
>>489 どの辺りが?>笑われる
HTTP POSTでも、サーバ側でセッション管理でも、その他お好みで。 HTTP GET併用でも、 > パスワードなどの値を渡すのには向いていない わけがない。ま、普通はパスワードと無関係なセッションID使うだろうが。
いまどきパスワードをGETで渡すバカいるかよー。
っていうかなるべくパスワードは頻繁に行き来させたくないんで hidden にいれたりもしないけど。
いま作るならほとんどセッションじゃないかなあ。
「P厨」 と
>>491 のはおもしろかったなw
>>498 get、postは流行りか?
バカめ。
ツマンネ(´・ω・)
フォームは定義リスト使え ってこったな あとな、hiddenないとできないとかいう低嚢プログラマーは消えろw
はいはいわろすわろす
>>495 どこが?
>>499 流行以前の問題だろw
セッションIDで管理するのは当たり前。
そして、たまにそのままPASSとIDを放り込んでる例があったってだけ。
>>502 getでセッションIDを渡すの?
文章の置き所間違えたけどわかるからまあいいや。
そもそも送信ボタンをボタンだと思うから、P要素で違和感を感じるんじゃ ないのか? ボタンとしてレンダリングされるのは一つの表示例に過ぎないだろ? 音声ブラウザなどを考えれば、送信ボタンなんてただのリンク文字列だよ。 「この内容で送信しますか?」と読み上げるブラウザがあってもいいような 要素じゃないのか? だったら、Pと考えても不自然ではない。いずれにせよ、 ボタンという見た目は排除して考えるべきだ。
type="hidden"とtype="text"を表示の違いと考えるのはおかしい。 閲覧者に入力(変更)を促すかどうかが根本的に違うぞ。
>>507 いや、機能だから。
音声ブラウザで機能を読み上げてるだけで、機能には変わりない訳だし。
内容と属性の値は違うだろ
>>509 A要素だってリンクを張るという機能があるが、段落の一部を構成出来る。
機能があるからと言って段落にならないという訳ではないだろ?
>>510 それは、その要素の設計によるはずだが。
<p>吾輩は<img src="cat.jpg" alt="猫">である。</p>
<p>吾輩は<a href="cat.jpg">猫</a>である。</p>
「画像と置き換える」「リンクを張る」などの機能が追加されていても、
根本的には段落の一部であって、内容か属性値かはその要素次第。
<input>はたまたま属性値を使うというだけだろ。
<p>記入事項に間違いがなければ内容を<input type="submit" value="送信" />してください。</p> といったものならいいんじゃない。 <p><input type="submit" value="送信" /></p> これは疑問。
<p><input type="submit" value="この内容で送信する。" /></p> セフセフ
アンカーってaタグで範囲を指定された文字列があるからpなんじゃ? 文字列にアンカーを張るっていう機能だから、 それ自体が機能でしかないinput type="submit"とは違うと思うんだが。
aタグ の検索結果 約 127,000 件中 1 - 10 件目 (0.06 秒)
>>514 aタグってなあに。
機能ってなあに。
ねぇねぇ。
機能 の検索結果 約 263,000,000 件中 1 - 10 件目 (0.14 秒)
hidden含めて ラベルくっつけて定義リスト これが最適 hiddenが機能とかいってるやつはあほだな じゃあ blink や marquee も機能だw
>>516 aタグってなあに。
ねぇ。
機能ってなあに。
ねぇねぇ。
「aタグ」とか言う表現は言いたいことはわかるけど 「機能」は何を指し示しているのかわからん。
そしてマークアップの為のマークアップにならないか?という質問がきてループ
なにここ 初心者が紛れ込んでるな aタグは <a 〜> とか </a> のことだろ
釣り上げようと必死な人が居ますね。
>>523 ttp://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.1 > Elements are not tags.
> Some people refer to elements as tags (e.g., "the P tag").
> Remember that the element is one thing, and the tag (be it start or end tag) is another.
> For instance, the HEAD element is always present,
> even though both start and end HEAD tags may be missing in the markup.
よくわからんが、アンカータグだろって指摘してるって事?
>>525 アホだろ タグと要素は違う
初心者しかいないみたいだな
まあ最初に言ったやつも区別ついてるかはしらんがな
aタグ <a 〜>, </a>
開始タグ <a 〜>
終了タグ </a>
a要素 <a 〜>〜</a>
>aタグで範囲を指定された ってあるから、 >aタグ <a 〜>, </a> これの事を言ってるんじゃ?w
>>528 たぶんそうだろ
まあ区別がついてなさそうな気はするがな
つっこんでるやつもわかってないようだしな
要するにあれ? 「タグ?(ププププ」 「それはタグじゃなくて要素って言うんだよwwwwwwwwwww」 っていう、最近覚えた知識をひけらかしたいお年頃のお方がいたって事?
>>530 たぶん、そうだろう
なんか aタグ って言葉自体につっこんでたしw
昨日からなんかひとり変なのがまじってるよなー。 web制作板にはいつになったらIDつくのかな。
と言う事を >aタグってなあに。 って言ってる人が自演して言ってそうだから、IDが見えないのは困るw
aタグでリンクという機能を貼っているのか? 本気で言ってるのか? 機能は、装備や実装やUAがうんにゃらかんにゃらした結果でしかないだろう。
ところでなんでこの板はID出ないんだ?
うんにゃらかんにゃらするようにしたものが機能なんじゃ?
>>538 だからお前の話は斜めだから話にならないんだって。
知識だけじゃなくて人間的にもっと成長しろ。
>>541 あーバカを見守れって事ね。わかった。じゃあタグは機能を貼るんだから命令です。それでどーぞどーぞwww
はい張り切ってスタート!
>実装の話は10中8, 9スレ違い。 じゃなかったのかー
>>542 は初心者スレでCGIはプログラムだってしつこく続けてた荒らしっぽいな。
やり口が全く同じ。
>>545 どっちもダメ。divに意味付けがなされていないから。
適切な意味づけをすればどっちもおk
>>546 てことは
<div class="section">
<h2>見出し</h2>
<p>ほにゃららららららららら</p>
<p>ほにゃららららららららら</p>
<p>ほにゃららららららららら</p>
</div>
ってのはStrictスレ的にありなのか?
前聞いたらさ
人間にしかわかんねーからダメだ
って言われたぞw
じゃあセクションはdivでくくるっていう自分ルールを作っておけば <div> <h2>なんとか</h2> <p>かんとか<p> ... </div> <div> <h2>あれや</h2> <p>これや<p> ... </div> はOK?
>>547 > って言われたぞw
って言われてもね・・・。
どう人間にしかわからないからダメかも聞いた?
classやidでの意味づけに意味がないって理由なら
divやspanの存在そのものが危ぶまれるよ!
>危ぶまれるよ! ワロタ
まず
>>146 に前者がダメで後者がダメじゃないという結論に至った経緯を説明してもらおう
問題提起をするならそれくらいしてもらわないと
form周りは難しいね 実装の話になるけど 各コントロールの描画についても OSやブラウザによってばらばらすぎるし
>>512-513 そうそう。段落かどうかなんて、前後の文脈とvalue属性値によるだろう。
<form>
<p>名前は<input>です。</p>
<p>メールアドレスは<input>です。</p>
<p><input type="hidden" value="上記、SessionID123456の内容を">
<input type="submit" value="送信します"></p>
</form>
こんなのなら、全部P要素でOK。
今までdl派だったけど、
>>512-513 みたいに一連の文章の流れの中だったらpでもいいように思えてきた。
あと、div派の意見もわからんでもないように思えてきた・・・。
おお、そういうきっかけになればあの一見不毛に見えた議論も無駄じゃなかったな。
>>556 の <input type="hidden" value="上記、SessionID123456の内容を"> の部分だけはちょっとあれだと思うけどw
> <p><input type="hidden" value="上記、SessionID123456の内容を"> > <input type="submit" value="送信します"></p> これは確かに違和感だな。 文章じゃなくてボタンだしw
どこまで加速するんだこいつらwww
宇宙一周するまでかな
>>507 <p>この内容で送信しますが、よろしいでしょうか? [送信]</p>
がOKで
<p>[送信]</p>
がNGなだけだ。
段落にオマケがついていても許されることはあるが、
段落じゃないものを段落として括るなという話だ。
あと、見た目がボタンか否かによらず、仕様としてあれはボタンだ。
実際テキストブラウザだとボタンじゃなくてアンカー付きテキストの
ように描画されるが、それでもなおHTMLとしてはボタンだ。
>>512 ,513,556
> value属性値によるだろう。
よらねーよ。仕様上、inputはフォームのコントロールで、valueは
コントロールの値の初期値だ。ユーザーエージェントが提出ボタンに
value属性値の値を表示するか否かでHTML上の意味が変わったりはしない。
で、inputはフォームのコントロールであって、imgのようにalt属性値が代替テキスト
として読者に示されるとされているような要素ではない。ボタンであると仕様に
明記されてるのを無視して、「valueの値が提出ボタンに表示される」なんて
実装に依存したものがHTMLとして意味を持つわけねーだろ。
value属性値に説明を書いても、それが文章としてなんて意味づけされない。
それが文章の一部として解釈されなければ段落として成立しない>512,513,556
なんてのは全部アウトだ。
いつも俺ルールで考えてるから他人の指摘をまともに聞けないんだよ
独り言のような一行レスはスルーで(俺含む)
<form> <dl> <dt>書き込む</dt> <dd> <dl> <dt>なまえ<dt> <dd><input type="text"></dd> <dt>メール<dt> <dd><input type="text"></dd> <dt>コメント<dt> <dd><input type="text"></dd> </dl> </dd> <dd> <input type="submit"> <input type="hidden"> <input type="hidden"> <input type="hidden"> </dd> </dl> </form>
なんかテーブルみたいだなw
>>562 段落に「おまけ」とかいうのが付いて許されたり、「おまけ」だけだと許されなかったりするなら何かで区切らないとね。
ぼく。
なんか一部分だけを拾ってきて全否定するやつってはなから人の意見とか聞く気ないだろ。
個人的な許容範囲 ○ <dt>名前</dt><dd><input/></dd> △ <li>名前: <input/></li> × <p>名前: <input/></p> × <p><input value="ここに名前を入れてください"/></p> ○ <p>名前は右のフォームに入れてください。 <input/></p>
>>569 アホやろ。理屈こねるなら辻褄ぐらい合わせろや。
>>568 > 段落に「おまけ」とかいうのが付いて許されたり、「おまけ」だけだと許されなかったりするなら何かで区切らないとね。
すでにご自分で区別がついてるように見えますが。
divの人は各コントロール個別にdivで囲んでるの? それともform以下のコントロール全てを一つのdivで囲んでる?
段落についてもう一度考えてみたいが、じゃあ、 × <p><img alt="花"/></p> ○ <p><img alt="街の片隅にひっそりと小さな花が咲いていた。"/></p> なのか? しかし、文になっていなければ段落ではないというのは本当か。 例えば小説の一節で、 | この送信ボタンを押せば、すべては終わる。永かった……。様々な | 思いが去来する中、震える手で俺は最後の動作を行った。 | 送信! こんなのがあれば、この「送信!」はこれで一段落だ。それを考えれば、 <p><input type="submit" value="送信!"/></p> もあり得るんじゃないか。
>>575 うん、だから、昨日のいつだか言ったけど、
前後の文脈によってならあり得るときはあるんじゃないか、って。
小説の一説とか日記の合間とかなら、画像だってそのときは P で囲むでしょう?
それは別におかしいとは感じない。
「単独」 で出てきた場合は文脈もなにもないから、おかしいと感じる、っていうことだったと思うけど?
>>575 > <p><input type="submit" value="送信!"/></p>
> もあり得るんじゃないか。
value属性値については
>>562 読みなおせ。
> ○ <p><img alt="街の片隅にひっそりと小さな花が咲いていた。"/></p>
絵単体が段落になるわけねーだろ。
代替テキストにすぎないalt属性値が表示されないと段落として意味を
なさないのに、段落を構成すると思う理屈を教えてくれ。
>>578 じゃあ
<P>あああ</p>
<なにか><INPUT></なにか>
<P>。</p>
じゃないと認めない。
>>578 表示されないと段落として意味をなさない?
表示されないと?
>>562 HTML4.01 仕様書 17.4.1 より
>User agents should use the value of the value attribute as the button's label.
shouldだね
>>583 >should以前に、それはtype="button"の説明ですよ。
その下の例示を見よ
>>584 > This form might be rendered as follows:
見ましたが、結局value値が表示されるのはsubmitやresetの
仕様じゃないですよね。実装依存ですよね。
submit も reset も button もひとくくりでいいっしょ。 <button type=""> でそれら全部の種類あるしなあ。
Strict的にはアウト
行間の読み方は人によって異なる場合があるから 仕様書にはっきりと書いてあること以外は mustやshouldどころかmay以下という認識・・・?ではない・・・?
>>588 > 行間の読み方は人によって異なる場合があるから
人によって読み方が異なって揉めることもあるんだけど、
>>581 がtype="button"に限った言及だってことは単なる事実。
まあ、それが分かってるから具体的な主張をせず、
仕様の文章を引用するだけとか、「見よ」とだけ言うとかで、
具体的な主張は避けるんだろうけどね。
結局、
>>575 がアウトだってことは変わらない。
仕様を読む限り、 submit も reset も value 属性の値をラベルにするのが自然に思えるなあ 仕様のエラーのような気がする
IE使ってるから。
なんか慇懃無礼な煽り口調の人が混ざってるね
P要素も、段落以外のものを含むのが自然と思えるからといって、 仕様を無視して段落以外を含んだり、仕様を無視してブロック要素である リストを含んだりしたら、それはValidでないHTML文書だよなあ。 仕様に不満があるからといっても、好き勝手にマークアップしちゃいけないよ。 やっぱり、divなりdtなり使いましょう。
>>595 文章以外のパラグラフも有り得るのではないか。
という話し。
段落、段落以外の話しとは違うよ。
そらありうるでしょ。 文章じゃない数式とかで証明とか書いたって パラグラフ になりうるしなあ。
>>597 それに<input>や<img>は有り得ますか?
じゃないの?
>>596 段落とパラグラフは別とかいう話じゃないのは、
パラグラフという言葉がこのスレで出てなかったことから明らかだな。
段落云々もパラグラフ云々も問題にしてることは結局同じだ。
で、「ありうるかもしれない、ありうるとかん変えている」と言うばかりで、
ここまでの段落でないもの単独をP要素として括りうるという主張は
全滅したんだし、そんなん無しでしょ。
いくら仕様が自分の思い通りじゃなかったからって、曲解は無しだよ、やっぱり。
いや、文章の中に画像がある場合もある、ってのはかなり前からいわれてるけど? なんでほどほどってのは知らないんだこいつら。
>>597 証明の文章中に数式が出てくるって形だろう。
文章中の数式単独で段落になったり、文中ですらない
単独の数式で段落になったりはしないんだから、
単独のinputをp要素とする話には関係ないよなあ。
単独のinputをPにする話なんかいましてた? それは昨日終わったと思ったんだがw いまは文章の流れの中の画像やinputとかも P にしちゃだめ、ってやつがでてきたんじゃないの?
img要素にalt属性で代替テキストを指定してる場合で、 それが文章になってるならpでもいいんでない?
インプット要素などの補足説明としてその要素の前後に文章を入れたりすることを考慮すると <form> <dl> <dt><label for="a">メールアドレス</label></dt> <dd>入力は半角英数</dd> <dd><input type="text" id="a" /></dd> <dt><label for="b">本文</label></dt> <dd>最大文字数1000文字</dd> <dd>800文字を超えると改行されなくなります</dd> <dd><textarea id="b"></textarea></dd> 続く </dl> </form> という具合に定義リストがスマートでないかい? dlファンなので他の要素での表記方法は考えていないけど。 ってこの話はもう終わった?
>>603 value属性値として文章を書いてinput単独をp要素とするやつが出てきたの。
>>604 代替は代替でしかないと思う。
value に文章入れてたらいいとか、title に文章いれてたらいいとか、それはやっぱないな。
仕様書に間違って読んでそれらしいことかいてあるなら考える余地はあるけど。
たとえば object の子要素は代替だけど、それを文章で書く場合のこと考えると、
<object><param/><p>text</p></object>
って普通書くと思うんだけど (違う?)
<p><object><param/>text</object>
</p>
こうかかなきゃ、ってことになるような気がする。飛躍しすぎたかも。
>>604 画像そのものでも文章や文章の一部として意味が通るならOK。
説明のなかで数式が出てくるときに、数式の部分を画像にしたりな。
画像じゃ文章(の一部)として認識しようがないものを、
「altに文章を書いたからPで括れるよねー」とか言うのはNG。
そもそも絵と代替テキストで意味合いが変わる時点でなあ。
で、そもそも代替テキストですらないinputのvalue属性値を文章
(の一部)としてP要素とするのもNGだろう。
ただ、type="button"のvalue属性値に文章(の一部)を指定した場合は
どうなんだろうね。
「あくまでもボタンだから文章の構成要素とはならない」となるのか、
「value属性値は閲覧者に示されるんだから、ボタンとはいえ画像と
同様に文章の一部として扱えると考えるべき」となるのか。
俺は後者だと思うなあ。
ただそれでも、input単独の場合は、img単独の場合と同様、
段落になりえないよなあ。
>>607 まれな例として、
文字コードの存在しない言語の混在する文章(小説とか)
ってのが考えられる。
一段落別言語が混在する程度なら、その一段落をまるまる
画像として段落扱いし、altには訳語でも書いときゃいいや、
という場合はアリだと思う。
(頻繁にその別言語が登場するなら、表現媒体を考え直した
方がいいと思うけどな。)
>>609 「扱える場合がある」 で充分じゃないかねえ。
画像にせよbuttonにせよオブジェクトにせよ、基本的にはないけど、
文章の一部で、それがないと一連の段落・構成としてなりたたないようなとき、かなー。
>>610 まあその例ならそうだろうけど、特殊なケースすぎるわー(笑)
身近に起こりそうな一般的ケースで話さないとちょっと議論しにくいね。何にだって例外はあるし。
>>607 画像が表示できない時に代替でテキストを表示するんだから、
画像と同じ意味というか説明になるテキストと同義って事にならないかなと。
そのテキストがpに当てはまるなら画像も当てはまるだろうしって感じで。
勿論、それゆえにtitleとかvalueは論外だと思うわ。
>>609 あくまで印象だけど、value属性値に文章(の一部)を指定する事自体が
違和感感じるなぁ。
>>613 逆かなあ。画像が当てはまるならテキストも当てはまる。
卵が先か鶏が先かじゃないけど、最初に代替テキストがあるのはおかしいかなと。
だって代替テキストなんて後付けで取り替え可能なものでしょ?
だいたい、画像と代替テキストは同じというかイコールとはなり得ないしなあ。
画像の持つ全ての情報を代替テキストで伝えられるなら別だけど。
普通こんな感じでしょ?
<img src="scene-a-15.png" alt="場面A-15の写真" />
こんな風にはそうそうかかないでしょ。
<img src="scene-a-15.png" alt="場面A-15の写真。止める女の言葉を無視し、男は剣を振りかぶり、無表情のままそれを振り下ろした。" />
書いたとして、「ALTが文章っぽくなたから P でいいね」、ってことだと変だなあ、って思うし。
>>612 要は、imgやinputであることが問題なんじゃなくて、
それが文章を構成しないのが問題なんだってこと。
で、結局「Pは段落以外に使うな」ということで話が一貫するわけね。
例外じゃなくて、もうちょっと基本に立ち返ってみよう、という話だな。
じゃないと、「imgがOKだからinputもOK」とか変な理屈が通っちゃう。
それのどこが変なのかをちゃんと説明すると、冒頭で言ったことに
なるってこと。
>>614 そういう場合もあるだろうけど、
画像がそれ自体で前後の段落を繋ぐ意味を持つときとかの話ね。
<p>そう、〇〇が△なんだ!</p>
<p><img src="nandatte.png" alt="な、なんだってー"></p>
<p>〜略〜</p>
みたいな感じで、MMRのなんだってーの画像を使って日記書いてる時とか。
要は使い方なんだけどね。
>>614 の場合だとちょっと適切ではないとは思うし、
あくまで状況によっては使える場合もあるだろうって考えてクリ。
>>616 最初からそういってくれないと誤解する(´・ω・`)
けっこう興味深い。
漏れは今まで、
>>616 の例を借りると
<p>そう、〇〇が△なんだ!<img src="nandatte.png" alt="な、なんだってー" /></p>
みたいな感じでやってたけど、この考え方だと漏れも
「<img>だけ<p></p>に入れることも容認」する派になるってことか。
>>617 すまんw
まあ、状況って色々あるじゃない?
一概には良いとも悪いともいえないと思うよって事なのよ。
>>615 >文章を構成しない
文章=段落=パラグラフ
ですかね?
確かに文字というか文章を代替する画像って場合もあるんだよな その発想はなかったぜw なんとなくの思い込みで、画像の代替としてのテキストとしか 考えてなかったと白状してみる
じゃあ画像が無いと成り立たない段落のテキストなんか書くべきじゃないよ。
仕様書はformの下にpの例文があります。
>>599 段落でないものをP要素として括りうるなんて主張してる奴はいないだろ。
単独の<img>や<input>でも段落になりうるという主張じゃないのか。
文になってなくても段落になりうるという話もあったし。
問題はP要素の意味範囲ではなく、段落の意味範囲なんだよ。
>>599 段落とパラグラフの微妙な違いについてはさんざん出てます。
>>621 paragraphが日本語の形式段落を指すか意味段落を指すか
どちらも指すか日本語の段落は指さない(無茶?)かは
議論の余地のあるところだけど、今回はそれとは別の話だよ。
それらですらないものをparagraph(段落)であると主張して、
p要素で括ろうとしてるのがいるわけ。
>>626 >305
>>630 じゃあ
<form>
<p>
<input>
</p>
</form>
は間違いであると。
>>623 画像が閲覧できる環境で見られるならなおよいけど、
代替テキストしか閲覧されなくてもどうにかなるなら、
img要素がないと成り立たないテキストを書いても
とりあえずOK。
それ以上踏み込んだ判断は、具体的な状況によるなあ。
>>628 過去スレの話じゃないです。このスレで始まった議論中で
出てなかったんだから、今回はだれも問題にしてなかった、
というのは明らかですね、ということですよ。
>>632 とりあえず過去ログ読もうよ。
>>74 あたりから始まるからしんどいだろうけど。
>>634 とりあえずOKなんてのはStrictではないです。
パラグラフは問題にしています。あなたが勝手に段落とパラグラフを別物に解釈しただけです。
>>635 読みましたよ。
途中で何度も同じ事をマンセーを集めて馴れ合いでくりかえしているだけ。
パラグラフの解釈はもう少し広いです。
例文を否定するならdl、dt、ddで会話をマークアップするのもダメですね。
形式段落と何とか段落とは別だとか 日本語文章での段落は何とかで英語文章でのパラグラフは何とかでどうのこうの・・・で よくもめてなかったっけ?
>>637 過去ログ読んでその説明を探して、それを踏まえてレスしてくださいね。
>>636 > あなたが勝手に段落とパラグラフを別物に解釈しただけです。
パラグラフと段落を別物に解釈したのは
>>596 ですよ。
>>596 さんに対してレスしてあげてくださいね。
>>638 >305
>>570 一番最後の右と云う表現は視覚的な情報。
俺なら絶対にやらない。
>>641 それは俺仕様書の俺Strictですよ。
div厨p厨以下です。
>>640 その議論で「文章をなさないinput単独でもparagraphだ」なんて
主張が出てきた覚えはないんだよなあ。文章なのは前提だったと思う。
つーか普通は文章前提だしなあ。一般書籍や数学の証明のように
文中に図画や数式が入ってくる段落ってのはあるけど、ボタンが
ポツンとあって「これは段落です」というのはないと思うんだが。
あるなら具体的に示してみてくれって、何度か言ってるけど、
返答はないよなあ。そんなんまで一般だったら、辞書の
総書き換えが必要だよなあ。
じゃあ、<input>が段落に入らないという人は、これはどうなの? <p><textarea>ここに文章を書いてください。</textarea></p>
>段落は文章が大前提。 でましたwww
内容がimgだけのパラグラフもinputだけのパラグラフも仕様書にあるがな。
つーか
>>262 ,272だな。Strict的にはダメらしい。
そもそも、英語の意味で、pタグは文章だけでなく図などの画像を含むから。 pタグで囲うべきだと思うよ。
つーか日本語の意味でも図画は入るし、
英語の意味でも650みたいのは含まんだろ。
で、
>>651 だ、というのがこの議論だろ?
>>650 で、結論だな。
仕様にあるとかじゃなくて、pタグは一つのくくりとして使うべき物だからね。
文章云々言ってる人はhtml知らない人だと思われる。
これからはもうdivは要らないな。 セクションdivもdivじゃなくてpを使うべきだろ。
例えば、穴埋め文章問題のテストを、CGIで自動採点するようなページを 考えてみる。すると、フォーム内は、 <p>1192年、<input>が征夷大将軍となり、鎌倉幕府を開いた。彼は…</p> このように、明らかにP要素内に<input>が入るだろう。そして、<input>の 現在値(ユーザーから入力された文字列)がその段落の文章の一部として 構成されることが分かる。 ところで、仕様書によれば、<input>はまず初期値(value属性値)を現在値 としてセットし、ユーザーの入力やスクリプトによって、その現在値が変更 されるとある。submitやhiddenも同様だが、これはユーザーの入力による 現在値の変更はないので、初期値がそのまま現在値となる。 ということは、これらをまとめると、submitボタンのvalue属性値なども 現在値として、文章の一部として構成されるので、文脈によっては、それ単独で P要素に入る事もあり得るという事にならないか?
>>658 それで合ってますが、
すいません…だいぶ前に結論出てるんですよ…
今更蒸し返さなくても…
>>658 いや文脈じゃないんだ。そうやって一回テキストとして文章として文脈を探るから外れる。
>>657 pタグは一つのくくりとして使うべき物なのに、
なんでブロック要素を含めないんだろうな。
仕様がおかしいよな。
>>660 文章の一部にinputが入ってる例にしかなってないよ
>>663 <input>の現在値が段落内の文字列になるという例だよ。
なら、submitのvalueだって、段落内の文字列になるから、
submit単体でも段落になり得ると。
>>664 原文をそのまま理解しろ。または初心者スレに池
<form> <div class=""> <label for="hoge1"></label><input id="hoge1" /><br /> <label for="hoge2"></label><input id="hoge2" /><br /> <label for="hoge3"></label><input id="hoge3" /><br /> <input type="hidden" /> <input type="submit" /> </div> </form> かんぺき!
このスレの住人が大好きなkanzakiでも、 メニューでdiv直下にspanとa置いてるよな。
>>662 それは一つのくくりとして使うべき物じゃないからじゃないか?
671 :
668 :2006/10/10(火) 08:14:12 ID:???
input type="hidden"だけを別途ddやらpやらその他何やらでマークアップしようとするのは
変だと思う。input type="hidden"を個別にマークアップしないと成り立たなくなる方法は
採用できなくなーい?
やっぱりフォーム周りは特殊だから
>>668 っすね!うん!
4.01時代の持ってきてもしょうがないね XHTMLの仕様書手抜きだよなーw
>>674 しょうがないとかw
じゃあどこの仕様書の例を参考にして賛成反対言ってるわけなんだぜ?
>>675 時代遅れで内容も古いからな
全てが当てはまるわけでもなく
結構いいかげん
>>671 ひとつのフォームの中のinputはinputだもの。
段落をテキストだの文章だの言ってるやつらが勘違いしてる。
そもそも<input type="text" />や<input type="radio" />や<input type="checkbox" />ほか input要素はそれだけだとパラグラフにもリストにも扱えないような。 <dl> <dt>性別</dt> <dd><label for="male">男</label><input type="radio" id="male" /></dd> <dd><label for="female">女</label><input type="radio" id="female" /></dd> <dd><label for="other">その他</label><input type="radio" id="other" /></dd> 〜略〜 </dl> などと何らかの文字列とセットならありかも知れないけど <dl> <dt><label for="name">名前</label></dt> <dd><input type="text" id="name" /></dd> 〜略〜 </dl> とか空っぽの入力ボックスがあるだけなのに 用語の定義としてマークアップされるのは気に入らねえ! いや、上記の例も「性別」という用語に対して「男」「女」「その他」が定義されているのは変か。
>>679 問題は文字列じゃないんだってば。低能。
>>679 いい加減もう消えてもらえないかな。
これ以上素人と話しても平行線だ
釣ろうと必死な人が2連続レスしています。
いろんな話題が混在してるから話がまとまらないんじゃない? imgだけinputだけをpに入れるのはどうなのよ、て話と form内はどうマークアップするのがいいの、て話と inputってそもそもどういう位置づけなのよ、て話と その他いろいろ入り混じってる 気がする
>HTMLはIEにページの表示結果を制御するためのプログラミング言語のことである。
いきなりのこれにお茶吹いたwwwwwwww
>>685 引っ掻き回したい人も混じってるから、そのせいもあるだろうな。
cool.ne.jpは見る気もしない
プログラミング連発w
禿wwwwwwwwwwwwwwwwwww
今までの話を各テーマごとにまとめてください 後から読むと話がかみ合っていないように見えます
>>685 p要素はブロック要素を含まない限りなんでも入れていいと主張する人と、
一般に言う段落(パラグラフ)じゃないものを含むなよ、という人の二つに分かれるよ。
>>691 一般的には、図とかの画像も1つの段落に含むんだが
どうも中卒レベルで話してる奴がいてなぁ
うんこするよ、うんこしないよ、うんこするけどすぐに消え去るよ、うんこじゃない別の何かをするよ、 みたいな系図で表現して
一般的には、といった表現が問題なんだと思う。 仕様書などを指し示して、ここに書いてあるじゃろがー って言わないと
それが書いてないんだわ
>>694 仕様の定義では、HTMLに限った特別な段落の定義をしてないから、
一般的な意味で考えるべきだよね、ということよ。
>>692 の言うとおり、世の中には画像や図も段落中に含まれることが
よくある、というのはさんざん言われてきたことだな。
けど、そこから飛躍して、「単なる画像だけでも段落と言う」「単なるボタン
だけでも段落と言う」と一般にない主張する人がいるんだよね。
あと、「type="button"なinputに限らずvalue属性値は必ず閲覧者に示される」
という誤った認識の上で、「value属性値が文章ならinput単独でも文章になる」
と主張する人も涌いては消え涌いては消え。
>>697 >「単なるボタンだけでも段落と言う」と一般にない主張する人がいるんだよね。
まぁ、HTMLだからww
> 一般的には、図とかの画像も1つの段落に含むんだが 例えば、 <body> <p><img src="photo_sakura.png" alt="桜の木の写真" /></p> </body> ってのはアリ?
もう水掛け論は秋田
>>699 ありっていうか、仕様上そうしないとダメ。
>>700 というより過去ログ無視して意図的にループに持ち込みたい様子。
>>697 一般ってどの分野の一般?
HTMLに関することを「一般」を引用して語るんだからHTMLの一般じゃないよね。
「段落」や「画像」や「ボタン」が存在する分野ってほかに思いつかないんだけど。
仕様上そうしないとダメって誰が決めたのw UL だって DIV だって許されてるでしょ。
「一般」「常識」「定説です」「最高ですか」は禁止。
>>703 お前は段落中に図や絵が出てくる書籍を読んだことがないのか?
というのが頻出。
そもそも、絵や図や段落やボタンなんて身近に存在するじゃないか。
絵や図は段落とともに現れることがあって、単なるボタンの出現は
段落と結びつくことがない、というのが一般でしょ?
>>705 「みんなも言ってる」「みんなも思ってる」「先生が言ってた」も禁止。
>>706 > 段落中に図や絵が出てくる書籍
画像をうpして
>>684 よく読んだらそんなに面白くなかった(´・ω・`)
>>706 はフォーム周りはどうマークアップしてる?
後半の意見が参考になったんだけどそれを
フォームのマークアップに生かそうとすると違和感を感じて
712 :
711 :2006/10/10(火) 18:22:24 ID:???
>フォームのマークアップに生かそうとすると違和感を感じて というかどうすればいいのか思いつかないだけだけど・・・
>>707 なんで? <div class="image"> とかでもだめ?
まあ
>>699 がアリなら <p><input/></p> もアリかなと思ったわけなんだが。
どう考えてもだめなんです
例えばディスプレイの設定ボタンが並んでいたらそれはボタンのリストなの? ボタンがあって、各ボタンにコントラスト、ブライトネス、って書いてあったら定義リスト? ・・・でいい?
>>715 文章や表示と構造は違いますよでFA。しつこい。
>>715 はどっちかというとチェックボックスに近いのかな・・・?
サブミットボタンは、ボタンそのものに何か文字や絵が描いてあるボタン?
だとしたらそれにさらに定義リストでマークアップそのボタンの定義を書くのは変っすよね・・・?
>>718 書いてある事は構造と違いますよでFA。しつこい。
>>717 > 文章や表示と構造は違いますよでFA。
formやinputあたりはずばりどうマークアップすればいいんですか・・・?
だから、考えてもだめなんです。しつこい。
一般の世界ではボタン上に文字や絵が書いてあるケースが多いと思う 一般の世界ではそれは段落ではないし段落の一部を構成するとも思えないけど、 じゃあそれをHTMLの世界に持ってきた場合は何に相当するのか、 そこが知りたい。 何にも相当しない場合はdivで?
あれもこれも違うけど、何が適切なのか言えない
( ´,_ゝ`)プッ
スルーしとけ
728 :
711 :2006/10/10(火) 18:38:04 ID:???
空気嫁よ
否定はできるけど自分の意見は言えない人がいるね、今。
>>730 紙とWebの違いから説明する気がしない。
紙とWEBが違うからこそ紙のルールを持ち込むことはできない
>>730 というか、「紙とは違う」とだけは言えても、
どう違うか説明して突っ込みどころ満載になるのは嫌なんだろ。
「違う」というだけでなんでも好き勝手できるなら仕様はいらんわな。
737 :
711 :2006/10/10(火) 18:47:14 ID:???
>>736 さんざん説明してるのに理解出来ないのはあなたが低能だからですよ。
>>737 表示されるかされないかで定義リストの項目から外すというのは無い。
すべてにおいて紙とウェブが違うと言っているのか、 フォームコントロールに関してだけ紙とウェブが違うと言っているのか、 それすらわからん。
>>738 そのレス番号を指し示してください
熟読します
自分で探せよ低能。
744 :
711 :2006/10/10(火) 18:55:13 ID:???
>>739 嫌い・・・って、定義リストを使ってhiddenとsubmitをどうマークアップするんですか?
スタイルシートを使わないすっぴんの状態でも意味を伝えるとしたら
回りくどくなると言うか冗長になるというか、そんな感じになりそうな気がするんですが・・・
発想が乏しいので変なのしか思いついていないだけかもしれませんが
IDがないと引っ掻き回したいやつがどれだかわからなくてだるいな。
>>743 さんざん説明してる…って…さんざん??
>>744 dlの項目としてはhiddenもsubmitも構造上違いはありません。
一般的には中卒レベルで話してるいい加減もう消えてもらえない素人と話しても平行線あなたが低能
>>361 マークアップの方法というか話のまとめ方がうまいな
なるほど、P厨はHTMLの構造しか見てないから 「構造さえ正しければなんでもあり」になるわけだな。
>>753 >>748 は
>>314 が正しいとか主張に対する人へのレス。
hidden属性は見えないから、submit属性は見えるからボタンだからという理由で別扱いするとかいうアホアホ理論の否定。
>>757 HTMLは構造のみ記述する言語じゃないのて
「構造上違いはないですよ」じゃ否定になってませんよ。
>>757 そもそも、マークアップの為のマークアップってどうなの?
>>757 見えるから、見えないから、ボタンの形をしているから、じゃなくて
labelをつける必要が無いから、じゃない?
ほかのinputにそろえるために不必要なものにまでlabelを付ける・・・てのは。
labelが不要だったらdtも不要で、となると定義リストである必要もない、と。
>>361 ってことだね
各項目に対して各人が個別に
項目名のラベルをつけるかつけないか判断する
>>758 それはおまえが文字列からしか構造をみないから。
>>762 私のものの見方がなんであれ関係なく、
HTMLは構造のみ記述する言語じゃないので
「構造上違いはないですよ」じゃ否定になってませんよ。
つか パラグラフ=段落=テキスト なんて論外。
また論点が入り混じってる。わざとか
少なくとも<input type="submit" />には<label></label>は不要だね
ttp://www.w3.org/TR/html401/interact/forms.html#h-17.9 > Some form controls automatically have labels associated with them (press buttons)
だから
<dl>
<dt><label for="hoge">(ここに何を書くのか知らないが)</label></dt>
<dd><input type="submit" id="hoge" /></dd>
</dl>
これはない。
>>763 divはその意味でも役割は有る。
他の要素で同じ事をするのはどうなんだ?
>>767 文盲wwwwwwwwwww何言ってんだおまえwwwwwwwwwwwwwwwww
>>769 は具体的に反論できない。「w」の数でわかる
バカを煽るな レスすんな
田植えするので精一杯
>>770 4文字レスは具体的に突っ込まなくていいから楽ですねw
得意げに具体例だして間違えてるバカに具体例を出してもわからないだろwwwww
>>774 >>730 ,736
今もまだいる。
ばかとかばかじゃないとかじゃなくてただの構ってちゃんだろうからスルーで。
>>778 おまえが煽ってるのに気付けよ。いいかげんにしろ。
>>777 hiddenはラベルを持っていないけどラベルを付ける必要がない(つけてもいいけど)でFA?
>>780 ラベルは必要だって人もいるので、結局著者の意図次第だなあ。
少なくともP直下にFIELDSETとかいうレベルでの「意味なし」というわけではない。
361で話がまとまってたんですね
並行するほかの話はまだっぽいけどね。
>>697 > あと、「type="button"なinputに限らずvalue属性値は必ず閲覧者に示される」
> という誤った認識の上で、「value属性値が文章ならinput単独でも文章になる」
> と主張する人も涌いては消え涌いては消え。
表示されるかどうかは関係ないだろ。<img>だって、画像が表示されるときは
altは表示されないが、altの内容が段落として成り立つものなら<img>単独でも
段落になるわけだし。
>>785 > <img>だって、画像が表示されるときはaltは表示されないが、
> altの内容が段落として成り立つものなら<img>単独でも段落になるわけだし。
なあなあ、altは画像に対する説明であって、altで伝えるようなことは
画像でもちゃんと伝えないとダメだぞ?
つまり、「画像単体じゃ段落じゃないけどaltの値は段落だ」という前提
自体がHTMLとして不正だよ?
んでまたinputのhiddenの話しが始まるだろ・・・ あーあ
ん?altって画像が表示される環境でも表示されなかったっけ? 画像を読み込むまでの間とか。
>>789-790 THX。なるほどね。
だけど、リファラとかの制限で画像が送られてこなかったりする場合や、
画像が壊れてる場合もあるから、その仕様のままだとちょっと不足だよなぁ。
画像が読み込まれる前の状態は、画像データを取得できなかったり
壊れてる状態とほぼ同じと言えるだろうから、その間表示されてるのは当然な気もするし。
とりあえず、まとめます Excellent!! = <p>あああああ</p> Poor = <div class="hoge">あああああ</div> Excellent!! = <p><img src="" alt="hoge"></p> Poor = <div class="hoge"><img src="" alt="hoge"></div> これで、わかったと思います。
(゜Д゜)ポカーン
Excellent!! = <p><input name="submit" value="submit"/></p> Poor = <div class="hoge"><input name="submit" value="submit"/></div>
Excellent!! = <p><object type="text/html" data="hoge.html"/></p> Poor = <div class="hoge"><object type="text/html" data="hoge.html"/></div> > hoge.html <body> <p>ほげほげ</p> <p>ふがふが</p> </body> なにか問題ある?
798 :
Name_Not_Found :2006/10/11(水) 11:38:53 ID:6F5qcgAN
ちょっと来てない間にこのスレ凄い伸びてるな。
>>797 その場合はむしろdivがいいんじゃ・・・
hoge.htmlの内容が何かわからないし、いろいろな場合が考えられる訳だし。
>>793 ,795,796,797
まとめる前に、770みたいな煽りで誤魔化したレス全部に
反論しなおしたら?
反論とかいいよ その「とりあえず、まとめます」も誰も真に受けてないだろうし
まぁ、正し過ぎて反論できないなぁ
現に誰も反論も何も出来てない。 不毛なスレもピタっと止まった。 まとめGJです!
>>786 画像と全く関係ないaltを付けたとかでもない限り、「altは段落だけど
画像は段落ではない」なんていう事態は起こりえないと思うが。
情報量の多い画像(写真など)はいくらでも訴えてくるものがある(物語らせる
ことが出来る)から、そういう画像はそれ単体で段落としての意味を持っている
とも言えるわけで。
例えばこんなaltが付くような画像。↓
<img alt="その女の子はこちらを向いてまるで天使のように微笑みかけていた。肩まで伸びた髪は…(略)"/>
>>804 ただ、そういった情景を描いた画像は、その情景を説明する文章とイコールではないような気もする。
これが img ではなく object だったのなら
<ul>
<li><object data="hoge.png" type="image/png">
<a href="hoge.png">hoge.png</a>
</object></li>
</ul>
という風に(自分なら)書くのですが……。
>>804-805 > ただ、そういった情景を描いた画像は、その情景を説明する文章とイコールではないような気もする。
これに尽きると思うよ。
だって、同じ画像についての説明でも、
段落形式だったり箇条書き形式だったりしうるもんね。
画像と、それの説明文って、違うものでしょ?
逆を言うと、
> そういう画像はそれ単体で段落としての意味を持っているとも言えるわけで。
というのが成り立つなら、段落形式の説明文を書けるなにもかもが
段落であることになるわけで。「じゃあ段落って何? 段落って、そういう形式のこと
だけじゃなくて、段落で説明されるものすべてが段落なの?」ってことになっちゃう。
>>803 ループが不毛だからしないだけだろ。
この1スレ使ってでたそのひとの結論が
>>793 ,796,797 じゃ、もう何も言うことないわ。
imgのみのpによるマークアップについての是非はまだ続いてるのね
>>806 イコールでないのは当然でしょう。あくまで代替文なんだから。
その画像が、ほとんど背景画像のように効果としてレイアウトされているだけ
なら、altは単純になるだろうし、ページ内の重要な意味があるのなら、それの
「代替」なんだから詳しくなるべきでしょ。
つまり、同じ単独画像でも、ページ内でどういう意味を持つのかによって、
リスト項目になったり段落になったりすべきなんだよ。常に段落にはならない
と考える方がおかしい。
誰かまとめサイトをつくって。
言い出しっぺの法則 と何度書かれたことか
>>809 > その画像が、ほとんど背景画像のように効果としてレイアウトされているだけ
> なら、altは単純になるだろうし、ページ内の重要な意味があるのなら、それの
> 「代替」なんだから詳しくなるべきでしょ。
altが単純か詳しいかと、altが段落か箇条書きかとは別の話だよね?
逆を言うと、altが段落形式で説明されるからって画像が段落形式としての
表現をしているかどうかとは別だよね?
>>806 でも
> 逆を言うと、
> > そういう画像はそれ単体で段落としての意味を持っているとも言えるわけで。
> というのが成り立つなら、段落形式の説明文を書けるなにもかもが
> 段落であることになるわけで。「じゃあ段落って何? 段落って、そういう形式のこと
> だけじゃなくて、段落で説明されるものすべてが段落なの?」ってことになっちゃう。
と指摘したよ。
> つまり、同じ単独画像でも、ページ内でどういう意味を持つのかによって、
> リスト項目になったり段落になったりすべきなんだよ。
だよね。altに拠るんじゃなくて、画像それ自身について考えれらるべきだよね。
リスト形式にはリスト形式という意味づけを、画像には画像という意味づけを、
段落形式には段落形式という意味づけを。
ページ内、つまりページ上でのHTMLにおける意味付けをするべきなんだよ。
要約してください ↓
>>812 altが段落形式で説明されて、画像が段落形式としての表現をし、
説明と表現の内容が一致する場合がある。
例: なんだってー!(MMRのワンシーン)
勿論、そうではない場合も有る。
これでいいじゃん。
しかも、結局そのhtmlの編集者の意図にそったものになるんだから、
画像の示す意味とaltの示す意味は一致させるのが当然と考えるよ。
altは本来は説明だけど、画像を選んだ人が説明を書くのであれば、
それは編集者がその画像を使った意図そのものが書いてあるって事だよね。
(勿論そうでない場合もあるけど)
だから一致しない状況ってのがそもそもの疑問だし、
意味や意図をわかってるんだから、pにするかしないか等の判断も出来て当然の状態。
なんか、考えがへんてこな状況設定になってないかね。
画像を選んだ人と、altの内容を考えた人と、マークアップの作業をした人が
全て別人の状態っていう、限定状況をベースにしてならその疑問が説明つくけど、
その場合は画像を選んだ人とaltの内容を考えた人の意図の不一致が問題なだけだし。
>>815 > 勿論、そうではない場合も有る。
> これでいいじゃん。
そんな限定的な結論はとっくに既出なのです。
> 画像の示す意味とaltの示す意味は一致させるのが当然と考えるよ。
表現の意味や意図だけでp要素となるわけではなく、
形式もp要素の意味付けとしては重要です。
段落としての形式でなければアウト。
画像の表現が段落形式ではないのに画像の説明が
段落形式である、というのはよくありますよね。
MMRの例では、台詞部分を考慮した全体が段落として
解釈できるかもしれないね、というような感じですね。
ただの花の絵は、どうみても段落形式ではないですよね。
「これは独自の言語で記述された文章で、この言語の
文法では段落である」とか主張するんでもなければ。
>>816 だから、作成者の意図どおりにすればいいんじゃない?
貴方にとってただの花の絵が段落形式に見えなかったとしても、
作成者にとってはその意味があるのかもしれないよ。
絵画や漫画のネタみたいに、ある程度の下地や知識がないと
理解できない類の場合もありえるからね。
ちなみに、MMRを例として出したけど、セリフは無くても全体が段落として
解釈できる場合も普通に考えられる。
のどの渇きに飢えている人の絵なりがあって、altで水をくれ・・・みたいな感じで使うとか。
ただ、これはたまたまわかりやすいだけであって、
これが何処までわかってもらえるかとは、また別の問題。
やっぱり製作者の意図を持って判断するしかない気がするな。
構成的にpでないとつながりがおかしい場合なら、必然としてaltもp形式にすればいいし、
どうにでもなる程度の融通の余地も有るんじゃないかね。
ちなみに、最初に文章があってそれの代替する表現として画像を使用するから、
pである必要があるって感じの状況の場合ね。
そういう前提無しにpである必要が・・・って考えるとドツボにはまるよ。
元々pでなくてもいい場合は、つながり的にも意味的にもpである必要は無いってだけだし。
>>817 > 貴方にとってただの花の絵が段落形式に見えなかったとしても、
> 作成者にとってはその意味があるのかもしれないよ。
それは仕様で使われる一般的な意味での段落ではないので
P要素とするには不適切なマークアップですね。
そもそも「段落形式の意味がある」という言葉が意味を成してないと
思いますが、「段落形式の意味」とはどういう意味の言葉ですか?
> やっぱり製作者の意図を持って判断するしかない気がするな。
意図によるとはいえ、段落の意味を製作者の脳内定義で捻じ曲げて
いいわけではないです。(それでは仕様の意味がないですからね。)
で、仕様書では段落について特段の定義はないので、一般的な
意味の範囲での段落と考えるべきです。(そうでなければ仕様の
意味がないですからね。)その範囲を越えるものはだめでしょう。
> どうにでもなる程度の融通の余地も有るんじゃないかね。
と言っているところからして、あなたと同じ論理で他のすべての要素を
DTD上正当であればどんな拡大解釈を適用してマークアップしようとも
問題ないということには気づいてないようですけど。
すくなくともその文書の言語として一般性に段落とみなせないものを
段落だと言い張ってP要素とするのはだめですね。
> のどの渇きに飢えている人の絵なりがあって、altで水をくれ・・・みたいな感じで使うとか。
とか。仕様を無視したマークアップをするんじゃなくて、その独自定義の
段落もどきは素直にdivでマークアップしましょう。
>>818 > P要素とするには不適切なマークアップですね。
P要素とするのは不適切なマークアップですね。
> 問題ないということには気づいてないようですけど。
問題ないということになってしまうことには気づいてないようですけど。
> すくなくともその文書の言語として一般性に段落とみなせないものを
すくなくともその文書の言語としては一般的に段落とみなせないものを
さすがに誤字が多くて意味不明だった。
Strictという仕様はHTML 2.0の時からあった訳だけど、HTML 2.0 Strict でも BODY直下にインライン要素を置いてはいけなかった。ただ、例外として IMG要素だけは直下に置いても良いという仕様だったんだよな。当然、 このIMGは単独画像となる。 当時はまだDIV要素がなかった時代。BODY直下にすべてのインライン要素を 置いてはならないとすると、単独画像をP要素に入れなきゃならなくなって、 そういう仕様にするのは違和感があったからだろう。 「単独画像をP要素に入れるのは違和感がある」というのは、ある意味、HTMLの 歴史が示している見解でもあると思う。 まあ、しかし、だからといって、完全に全ての単独画像がP要素に入らないかと 言われれば、そんなの断言出来る訳がないが。
なんか否定の仕方が???って感じだね。 普通に文字の代替として画像を使う場合があるのに、 画像は一般的な段落ではないから否定されるってのがそもそもおかしい。 紙に書いた文書の途中に、後から別の紙に書き足した文をくっつけてもそれは段落だし、 それがコピーでも印画紙に焼き付けられた写植でも、段落な筈なんだけどなぁ。
>HTMLの歴史が示している 都合よすぎる妄言だな。 CSS勧告を見据えて作られたのが、DIVとSPAN。 これら要素型の、CSSを無視した有用性は、全て後付のアイデアである。
>>821 なんか肯定の仕方が???って感じだね。
> 普通に文字の代替として画像を使う場合があるのに、
> 画像は一般的な段落ではないから否定されるってのがそもそもおかしい。
という話はこの話の最中ですら否定されてないのに、そこから
「だから作者が段落だと言い張るだけでなんでもP要素として扱える」
という主張への飛躍を埋める説明は、結局できないんだもんな。
完全に電波スレだなこりゃw
「単独画像はP要素に入れる」派って、「DIV直下にインラインは入らない」派の人?
関係あるかどうかわからないけど、 「Copyright c 1994-2006 hogehoge All Rights Reserved」 ってのは何でマークアップしてる? するべき?
addressかul
<dl> ・・・ <dt>Copyright</dt> <dd>© hogehoge All Rights Reserved</dd> </dl> とか?
>>823 鸚鵡返しって、イニシアチブを取りたい人が思わずやってしまうらしいよw
俺はさも余裕ってアピールする行為って感じ?
自演乙 見るまでもなく間違いだらけで使えなそうだw
なんかXHTMLっぽいのでブログとか作ってる人ってけっこー全てのタグに id とか class とかつけてたりしてちょっと気持ち悪いよね(´・ω・`)
それはスクリプト側で処理しやすいようにじゃないの?
Strictとは直接関係ないし、生理的にどうこうというネタでもないな。 データを再利用しやすくなる。ただし転送量が増える。それだけのこと。
「再利用しやすくなる」かどうかは分からないというか、場合による。 それ以前に、まずは、文書作者が利用しようとする意志があるのだろう。それだけのこと。
>>834 はサイト制作者が再利用しやすいようにidやclassを振ってるんだろうって言ってるんじゃないの?
837 :
Name_Not_Found :2006/10/16(月) 22:33:54 ID:I1Rtr86B
「HTML の神髄を追求する」なんて言いながら パラグラフが成立していない文章を書いてる奴は白痴。 つまりばげらのことなんだが、他のW3C信者にもあてはまる。 W3CのHTMLチェッカのバナー貼りつけていながら 全く構造的でない文章を書いている奴も馬鹿丸出しで痛すぎる。 なんとなく意味のまとまりで区切ってるだけで パラグラフという概念がそもそもないんだろうな そんな白痴がStrict-HTMLと宣っているこのくそったれな現状
何か嫌な事でもあったの?
あのステッカー貼ってる時点でstrict的にはおかしいわなぁ。 その画像がないと成り立たない文書なら貼るべきかもしれないがねぇ。ステッカー貼らないと成り立たない文書ってナンダそりゃ?!って話しだねぇ。 まあウザいこたウザいやねぇ。
840 :
Name_Not_Found :2006/10/16(月) 23:08:15 ID:I1Rtr86B
いやいや、Strict-HTMLを書くためにはパラグラフの概念が不可欠だと言いたかっただけ。
>>839 「作成環境」 のとこに 「XHTML1.0」 とかって書いてて、CSS の background で画像指定してたりするのはおkですか?
>>840 論文の類なら確かにその通りです。
ただ、小説やそれに近い文章では「パラグラフ」の概念自体が
存在しない(事もある)のですが、どうしたら良いのでしょう。
本当にそう思うなら全部preだ!
845 :
Name_Not_Found :2006/10/17(火) 00:33:05 ID:QyF7ITTf
つかね。 strict狂信者の基準に合わせろって方が現実的にありえないんですがw strictの一般的な基準値と、狂信者の基準値は大きな乖離があるのに、 それを考慮に入れず他人に自分の価値観を押し付けるような事をするから、 ストリクタは嫌われるんだよ。 いい迷惑。
> パラグラフの存在しない小説やエッセイの類はHTML文書にすべきではない えええええ。
>>846 strict狂信者の基準に合わせろなんて誰が誰に言ったんだ?
>パラグラフという概念がそもそもないんだろうな W3CのHTMLチェッカのバナー相手にここまで要求してる時点でダメじゃね?
850 :
Name_Not_Found :2006/10/17(火) 18:55:41 ID:QyF7ITTf
チェッカではなく書き手の問題のつもりだったんですがね
同じっしょw チェッカを通ったらOKレベルのやつにそこまで求めるのがおかしい ここで要求されるようなレベルよりちょっと下までを考えてるのだとしても、 もっと厳密な審査wをしないといけないしな そこまでやる訳が無いし、現実的に考えて不可能
特攻野郎Aチームならやってくれる
チェッカを通ったらOKレベルのやつにそこまで求めるのがおかしい
ことを求める
>>851 さん。
誰もまとめないのなら、テンプレ作るべ。 Lv.1) W3CやAHLのチェック100点 Lv.2) div, spanは必要最低限 Lv.3) paragraph != (日本語で言う形式)段落としてp要素を扱う Lv.4) ... ... Lv.100) TBL を超えた ネ申の領域 てな感じでどんどん追加してって
・div, spanは他にどうしようも無い時以外に使ってはいけない。 というか、使ったら負けだと思っている。 このスレだと、これぐらいの要求してくるよなw
>>857 まあそういう人は多いだろーね。上のレスとか読んでてもそう感じる。
P厨乙。
そして無限ループ
完璧に完璧を極めようとしたら、文章の方を合わせていくしかない けれどそれだと実用的ではない→XMLでやれ でもXMLでもレンダリングでどーせXSL変換する (しなくてもいいけど、一般的にみればもっと実用的じゃなくなる) 体裁ばかり拘って意味解釈無視するならPDFとかにしちまえというなら同意だけれど、 意味的にみてあからさまにおかしくない解釈、用法はあるていど認められていいと思う
>>864 > 完璧に完璧を極めようとしたら、文章の方を合わせていくしかない
パラグラフ云々はdivやspanを使えばOK。
divの乱用を嫌うあまりに、divを使わずに済む理屈を考え出そうと
するからおかしなことになるだけで、使えばいいのよ、divを。
divを使わんでいいところに使わない、というのは当然だけど、
divを使えばいいのに「文章を変えよう」となるのは立派なdiv厨だな。
まだあきらめないのか低能。
divから卒業しようぜ
おまえはまず入学しろ。
アンチDIV厨UZEEEEEEEE こうですか? わかりません
アンチDiv厨は普通にうざくね?
div寄生虫うざす
○○厨と言うときは、それの信者とアンチをセットで厨として 扱ってることになるらしいよ。
そうですか
また、div中毒者が暴れてるのか
アンチdiv厨っていうと、なぜかdivをちょっとでも使う人 全部を批判するようなレスがくるよな
じゃー P厨って言えばいいんじゃね? じゃね?
人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。 人の脳を読む能力を悪用する奴を潰せ。
例のキモイコテの発言だからな。 それぐらいの破壊力はある。
人の脳を読む能力を悪用する奴を潰せ の検索結果 約 2,380 件
サイコパスか
Kingだろ
今までStrictで書いてたんだけど、 自動で挿入される広告バナーが全然Strictじゃないことにさっき気づいた。 泣く泣く全頁をTransitionalに書き換えた。
887 :
KingOfUniverse ◆667la1PjK2 :2006/10/25(水) 17:46:28 ID:sMd94OyH
talk:
>>878 ,
>>882 人の脳を読む能力を悪用する奴を潰せ。
talk:
>>884 私を呼んでないか?
XHTML 1.1 などでは <a href="a"><span><a href="b">c</a></span></a>のような書き方ができそうですが、
XHTML 1.1 などでは a要素のどの階層の子要素にもa要素を入れられないという規則はありますか?
また、 html 要素を一つだけ必ず入れる必要があるという決まりはありますか?
888 :
KingOfUniverse ◆667la1PjK2 :2006/10/25(水) 17:49:46 ID:sMd94OyH
talk:
>>885 body部の先頭または末尾にdiv要素を使ってその中にobjectかimgでgif画像等で埋め込めばいいのだが、SSIをどうするかはサーバー管理者が決めることなんだよな。
お前はたいした知識もないのにでしゃばるな。 つか、うざいから消えろ。
infoseekは</HTML>の“後”に広告を挿入する。 しかも終了タグがあるのに開始タグがなかったりする。 酷すぎ。
</html>の後でも広告表示されるの?
892 :
KingOfUniverse ◆667la1PjK2 :2006/10/25(水) 18:34:21 ID:sMd94OyH
広告の表示自体は消すことも可能だが、問題なのは広告が表示されることではない。
talk:
>>889 何考えてんだよ?
>>892 問題はわかっとるがな。Strictスレだもの。
894 :
KingOfUniverse ◆667la1PjK2 :2006/10/25(水) 18:46:51 ID:sMd94OyH
再掲。 XHTML 1.1 などでは <a href="a"><span><a href="b">c</a></span></a>のような書き方ができそうですが、 XHTML 1.1 などでは a要素のどの階層の子要素にもa要素を入れられないという規則はありますか? また、 html 要素を一つだけ必ず入れる必要があるという決まりはありますか?
規則があるかどうかなんて仕様書読めば解るでしょ。
>>890 Stricterなあなたに、広告非表示オプションがあります。
もしかしたら、このためにわざとひどいコードだったりしてね。
897 :
KingOfUniverse ◆667la1PjK2 :2006/10/25(水) 19:33:48 ID:sMd94OyH
talk:
>>684 どういう点においてperfectなのか?
talk:
>>895 しかし、XHTML でもa要素のどの階層の子要素にもa要素を入れられないというような説明があるサイトがある。
898 :
KingOfUniverse ◆667la1PjK2 :2006/10/25(水) 19:39:55 ID:sMd94OyH
899 :
KingOfUniverse ◆667la1PjK2 :2006/10/25(水) 19:45:13 ID:sMd94OyH
そのサイトでは、「a要素タイプは結構複雑な内容モデルとして示されています。」と書いてあるだけのようだ。
A要素なんかなくなるんだぜ?おまえナニ言ってんだぜ?
Modularization of XHTML™の内容モデルだと (PCDATA | Inline - a)* となっている。
DTD上はa要素の入れ子はできるだろ してはいけないのとできるのとは別
903 :
KingOfUniverse ◆667la1PjK2 :2006/10/25(水) 20:34:17 ID:sMd94OyH
talk:
>>901 それでも、<a href="a"><span><a href="b">c</a></span></a>のようにはできるのではないか?
それが必要な具体例がまったく想像できない。
フィッシングとか
906 :
KingOfUniverse ◆667la1PjK2 :2006/10/25(水) 21:41:33 ID:sMd94OyH
talk:
>>904 [
>>901 ]に対しては、XHTML 1.1 のDTDではそのような記述ではないと答えるべきだったか。
痛い素人がいるなw
908 :
KingOfUniverse ◆667la1PjK2 :2006/10/25(水) 23:35:47 ID:sMd94OyH
html要素が無い文書もXHTML 1.1 等のDTDには違反していない?
自分一人で調べればわかることをなぜ掲示板で問う? 機械的なインターフェースでない人間相手に二人分のカロリーを消費して誰が得をする?
してはいけないのとできるのとは別 うざいから初心者スレいけ
DTDで書けるからといってHTMLとして正しいとは限らないよ。 例えば、 The THEAD, TFOOT, and TBODY sections must contain the same number of columns. とか、 Anchor names must be unique within a document. とか。
相手すると居付くから放置汁。
913 :
KingOfUniverse ◆667la1PjK2 :2006/10/26(木) 07:00:47 ID:Fw2H6e4E
talk:
>>909 無いことを調べるにはどうすればよいのか?
そりゃ、仕様に存在しないなら仕様違反ってだけだろ。 いい加減うざいからどっか池。
915 :
KingOfUniverse ◆667la1PjK2 :2006/10/26(木) 17:37:41 ID:Fw2H6e4E
それではxml宣言とDOCTYPE宣言だけを書いてXHTML 文書だと主張してもDTDには違反せず、 内容モデル、属性、属性値が正しい要素を html 要素を書くことなく書いても、 <a href="a"><span><a href="b">c</a></span></a>としても、DTDには違反しないということでいいのだな? 私が調べた限りではそうだった。 とにかく、XML の DTD は XHTML には合わないということでいいのだな?
しつこい
>>915 a要素の件は、XHTML 1.0がHTML 4.0(4.01?)のXMLベースの再構築版で、そっちの仕様書だかDTDだかで確か禁止だから多分禁止じゃなかったっけ?
そもそも、何故aを二重化するのにこだわるの?正当な「Valid XHTML」マーク付きのフィッシングサイトが作りたいなら分かるけど。
あと、合わないも何も、XHTMLはXMLベースだからXML DTDで定義するでしょう。
それにDTDに違反しないのを目的にXHTMLを使っているの?少なくとも自分は違う。大体DTDだけを取り上げるならdiv中毒もblockquoteのインデントもOKだろうし。
もしそれらが可能だとしても自分ならしないし、絶対正当な書き方で書いておけばいいんじゃない?
html要素省略するメリットも思い付かないし。
どうしても疑問ならW3Cの人にメールした方が「確実」な答えが返ってくると思うよ。きっとこのスレにHTML/XML/XHTMLの仕様策定に関わった人いないし。
それを踏まえて、現状に不満ならXML DTDの仕様変更の要望書を出したらいい。
要するに、
続きはW3CのMLでしたら?
他の人、長々とごめんね。
>>915 >xml宣言とDOCTYPE宣言だけを書いてXHTML 文書だと主張してもDTDには違反せず
>内容モデル、属性、属性値が正しい要素を html 要素を書くことなく書いても、
仕様書には"The root element of the document must be <html>."とあるが、
DTDには書いていないから確かに「DTDには違反しない」。
><a href="a"><span><a href="b">c</a></span></a>としても、DTDには違反しない
<!ENTITY % a.content
"( #PCDATA | %InlNoAnchor.mix; )*"
>
>XML の DTD
そんなもの無い。
Extensible Markup Language (XML) 1.0 (Fourth Edition) 2.8 Prolog and Document Type Declaration Validity constraint: Root Element Type The Name in the document type declaration MUST match the element type of the root element.
920 :
Name_Not_Found :2006/10/26(木) 18:51:25 ID:xlVJb77r
inputでラジオボタン30個ぐらい並べてるんだけど tabindexナンバー全部割り振らないといけないのでしょうか?
922 :
920 :2006/10/26(木) 19:39:47 ID:xlVJb77r
先程割り振ったんですけど タブ打っても順番にいかないのだけど。 ただの記述ミスなんですかね。
>>922 うん。たぶん。
でも、仕様と実装が違う事も多々あるし。
つか、根本的に
924 :
KingOfUniverse ◆667la1PjK2 :2006/10/26(木) 20:55:54 ID:Fw2H6e4E
talk:
>>918 それでは、%InlNoAnchor.mix; が何を参照しているか調べてみろ。XMLで認められるDTD.
talk:
>>919 XMLの説明の方に、 XHTML 文書は 必ず一つだけの html 要素を含まないといけないことがあるのか。
さて、残りはアンカー関係だ。
>>924 ここは『Valid』HTMLスレじゃなくて、『Strict』HTMLスレのような気がするんだけど、違うかな?
HTML4.01 では DTD Invalid な文書でも XHTML1.0 では DTD Valid になったり、 その逆になったりすることがあるというのは、何スレか前にも話題になった事。 <a href="a"><span><a href="b">c</a></span></a> はHTMLではInvalidだが、XHTMLではValid。 逆に、 <ul><ins>a</ins><li>b</li></ul> はHTMLではValidだが、XHTMLではInvalid。 添加要素と排除要素の問題だが、そもそもどちらもわざわざそんな書き方を する必要がない。
928 :
918 :2006/10/26(木) 22:26:16 ID:???
>>924 <!ENTITY % InlNoAnchor.mix
"%InlNoAnchor.class;
%Misc.class;"
>
再帰的に調べればよいので以下省略。
で、「XMLのDTD」ってどのファイル?「XMLで認められるDTD」ってどういうこと?
>>928 a要素の内容モデルは ( #PCDATA | %InlNoAnchor.mix; )* だから、
a要素を子要素とすることは出来ないが、
span要素は ( #PCDATA | %Inline.mix; )* だからa要素を子と出来る。
従って、
<a href="a"><a href="b">c</a></a>
は DTD InValid だが、
<a href="a"><span><a href="b">c</a><span></a>
とspan要素を噛ませば DTD Valid になる。
SGMLではDTDで「子孫すべてから排除する」という書き方が出来るが、
XMLではDTDは子しか指定してはならないからな。…って話だろ。
>>920 タブインデックスはブラウザ依存だから、やらない方が良いよ
Strictな具体例を示さないとさ。 Aの中にA。そして回避ではなく意味のあるSPAN。 なんですか?どんな場合ですか?
932 :
918 :2006/10/26(木) 23:48:05 ID:???
>>929 ありがとう。
<p>しかし、私は上記に加えて、
<object>
<ul>
<li>水筒</li>
<li>タオル</li>
<li>ちり紙</li>
<li>ビニールシート</li>
<li>ビニール袋</li>
<li>雨具</li>
</ul>
</object>
も、必需品ではないかと思うのだ。</p>
が良いかどうかと同じ話か。
構造や手法は同じっちゃ同じだが、ある要素の中に回避要素かませて同じ要素を含む、ってのは よっぽどレベルが低いか奇抜で画期的なアイデアか、のどっちかに思えるが。
奇策っていうか、仕様をむりやり回避してるだけのダメマークアップじゃんw ここはStrict-HTMLスレだぞ。
むりやり例を考えてみた。w <a href="law"><em><a href="newton">ニュートン</a></em>の法則</a>
普通にどっちかでよくね?
937 :
KingOfUniverse ◆667la1PjK2 :2006/10/27(金) 19:33:11 ID:zf55ymDX
talk:
>>931 ハイパーリンクの中にさらにハイパーリンクを埋めてみようと思う人はやはり居ないか?
私が知りたいのは、XHTML の DTD で a要素のどの階層の子要素にもa要素を入れられないのかどうか、だ。
どっちつかずの説明をしているサイトがあったから議論をした。
DTD対応のXMLパーサにかけたらいいって問題ではないの?よく知らないけど。
>>937 結論は出たんだからもう来なくていいよ。
>>937 まずa要素の入れ子が必要な事例を挙げてくれないか?
想定され得る事例があれば議論も成り立つと思うのだが。
>>939 「常識的に」の中身が「DTDに沿う/沿わない」なのか「Strict思想に沿う/沿わない」なのか。
>>942 同意。
DTDに合致すればValidだけど、 仕様はDTDの他に仕様書によっても規定されていて、 仕様でaの入れ子は禁止されている。 解釈の余地の範疇の問題のStrict思想云々とは別で、 議論の余地なく単純な仕様違反。
【まとめ】
HTMLでは、
・DTDで、a要素内は子々孫々に渡ってa要素を入れる事を禁止している。
・仕様書本文でも、a要素内にa要素を含む事を禁止と書いてある。
XHTMLでは、
・DTDでは、子のa要素は禁止しているが、孫以下なら禁止されていない。
・仕様書本文(XHTML1.0)には、「XMLの制約上DTDに書けなかったが
孫以下にもa要素を入れるのは禁止」と書いてある。
Strict思想的には、
・一応、
>>935 は構造的にはあり得るかな。ニュートンに関する話と、
その法則に関する話は別の話だから別リンクなのはあり得るし。
結論……構造的にあり得て、DTDが許していても、仕様として禁止。
>Strict思想的には、
>・一応、
>>935 は構造的にはあり得るかな。ニュートンに関する話と、
> その法則に関する話は別の話だから別リンクなのはあり得るし。
ここは同意できん。
Strict-HTMLを語る前に日本語を勉強してこいよ・・・
仕様書に書いていることでスレ消費するなや あほか
XHTML2.0だとネストしたアンカーは普通に使えるっぽな。
ストリクタはとうとう仕様書に明言してある事も超越するようになったのか?w
HTML4.01 や XHTML1.0 では、a要素のネストは仕様書で禁止されているが、 XHTML1.1 では言及がない。XHTML2.0 ではまだ議論中のようだが「ユーザー エージェントはネストされたリンクを扱えるメカニズムを提供すべき」と 書いてあるのでネスト出来ると思われる。 というわけで、XHTML1.1 でネスト出来るかどうかは仕様書に言及がない以上 微妙な所だな。
1.1なんてapplication/xhtml+xmlの時点でIEで見れない時点でまだまだ先の話じゃない。 そもそも対応する気もないらしいけど。
>>953 まじかよ……MIMEタイプの対応ってそんなに難しい実装なのか?
難しいじゃなくて、対応する気が無いらしい。 XMLにあまり出てきて欲しくないのかもな。
MS曰く、「ユーザが望んでいるのは標準仕様への対応ではなく、多くのページを表示することだ」らしいよ。 application/xhtml+xmlに対応すればより多くのページを表示することができると思うんだけどな。
>>955 マイクロソフトほどXMLを積極的に利用してきたベンダーは他に無い。
>>956 「表示」に限れば、初期のtext/xmlにそれらを加えても、実質的な意義が無い。
HEADリクエストで調べるとかなら、意義があるが……。
まず、text/xml; type=xhtml みたいな書式にしなかった事がおかしい。
そして、IE6が世に出るのを待っていたかのように、直後にRFCを出した事もおかしい。
マイクロソフトからすれば、まるで梯子を外されたようなものだろう。
自社OSのXML環境が整うまでXHTMLの放置プレイは続く
>>952 XHTML1.1はModularization of XHTMLベースで、Modularization of XHTMLには(PCDATA | Inline - a)*と書いてあるからXHTMl1.1でもネストできない。
>>959 いや、Modularization of XHTMLのDTDを見ても、a要素の孫要素にa要素が
書けるようになっている。
それに「Inline - a」の意味は4.1章に書いてあって、単にInlineからa要素を
除いた部分という意味しかない。SGMLでの「- a」(子々孫々から除く)
とは意味が違う。という訳で、子からは除かれるが孫からは除かれない。
なるほど、奥深いな。
>>957 ふと思ったんだが、「type="text/xml; type=xhtml"」って少しカッコ悪いな。
というか、みんなそんなにリンクをネストしたいのかよ、わざわざspanとか挟んで姑息な回避策つかってまで。
いまさらだけど <P><A>ニュートン</A>の<A>万有引力の法則</A></P> だろ。 <P><A>ニュートン力学</A>における<A>万有引力の法則</A>。</P> とか。(大文字と属性省略はわざと)
>>963 別にニュートンの法則でなくても、オームの法則でもボイルの法則でも
何でもいいんだが…。そしたら、そういう自然な言い換えも出来ないよな。
もちろん、
<a href="newton"><em>ニュートン</em></a>の<a href="law"
title="ニュートンの法則">法則</a>
みたいな書き方もありえるが、
>>935 もStrict的構造として変な訳では
ないかなぁと。あとは仕様が許すかどうかの問題だけで。
>>964 なるほどね。
考え方として有り得るか有り得ないかなら、有り得るね。
やるかやらないかなら、やらないね。
出来るか出来ないかなら、当分出来ないだろうね。
そんなこんなしてるうちにa要素もhref属性も無くなるもんね。
英文とかで、 I like: ・apple, ・orange, and ・strawberry. とか書くことがあるけど、これはul? ol? 意味的には順番は関係ないけど、文としては I like: ・orange, and ・strawberry. ・apple, みたいに順番を変えてしまったらおかしくなってしまう。
<p>I like: apple, orange, and strawberry.</p>
I like: ・apple ・orange ・strawberry
>>966 英文で、そういう単語や短いフレーズを列挙する場合、重要なのは、最後のリストのピリオドだけ。
リスト化した時点で、カンマまたはカンマ + " and" の役割は消失するから、余分な塵になる。
また、LIでマーク付けしているから、UAにとっても、カンマまたはカンマ + " and" は不要である。
結局、閲覧者に対してもUAに対しても、この時点で、カンマまたはカンマ + " and" が不要である。
次に、ULかOLでマーク付けしているから、UAにとっては、ピリオドさえも不要になる。
しかし、英文としては、ピリオドを書くのが普通である。
つまり、閲覧者に対してピリオドが必要であるならば、装飾として提供した方が良いのではないだろうか。
余談だが、そういう単語や短いフレーズを列挙する場合、実は、コロンを書かない方が好ましい。
センテンスや長いフレーズを列挙をする時に、各リスト文末にセミコロンを使う事があるが、そういう場合にこそコロンを使う。
個人的には、C言語のswitch文内に見られる、
case '0':
i++;
break;
のような、文を列挙する形式に見られる、コロンとセミコロンの使い方が、いかにも英語的だと思っている。
「ulは入れ替えても意味が通るようなものに使う」というのは
言い方はわかりやすいものの若干ミスリーディングだと思う
ordered/unordered は形式的順序のことを指しているのではなくて、
リスト要素の内容の意味的な順序と理解した方がいいと個人的には思っている
>>966 の上の例は許容範囲としたい
【うざい】Strict 39【仕様書嫁】
振りっぱなしでは申し訳ないので とりあえずHTML3.2の仕様書にLIがblock-levelであると書いてあること、 及びその用途、性質からしてLIはblock-levelであると自分を納得させて向こうは完結いたしました もし邪魔でなければこちらの皆様のご意見も聞いてみたくはありますが、 お邪魔でしたらこれにて失礼させていただきます
976 :
KingOfUniverse ◆667la1PjK2 :2006/11/05(日) 11:27:41 ID:R2e0JDcq
MS社が、ユーザーが望んでいるのはより多くのページを表示することだとするのなら、 MS社は Internet Explorer の仕様書を提供するべきだ。
977 :
KingOfUniverse ◆667la1PjK2 :2006/11/05(日) 11:30:41 ID:R2e0JDcq
Internet Explorer の仕様書があってもよくなる訳ではないだろうな。 HTML文書を書く人が、綺麗にマークアップした方がよい。
いや、blockでもinlineでもないんだろう。 だから、LIは、ULやOLの直下にしか出現できないし、 DDは、DLの直下にしか出現できない。
>>975 次は、COL要素がblockかinlineかと気になってくると予測。w
仕様書には、BODY内の要素は certain がblockで others がinlineとあるが、
"the others" とは書いてないから、必ずどちらかに分類されるという話には
ならないだろう。
980 :
Name_Not_Found :2006/11/05(日) 15:29:33 ID:oAQX0A6U
>>979 なるほど!ものすごく納得出来ました!
ということは%blockがblock-levelで%inlineがinlineとする3.3.2と7.5.3はそもそも矛盾していなかったということなのですね
英語力の無さを露呈してお恥ずかしい
これでやっと明日から安らかに眠れそうです
大変ありがとうございました
%block=ブロックレベルエレメント なのか? イコールなのか?
address要素を1ページに2個以上含めるのって別に問題ないですよね?
>982 You will encounter two DTD entities frequently in the HTML DTD: "%block;" "%inline;". They are used when the content model includes block-level and inline elements, respectively (defined in the section on the global structure of an HTML document). とあるからイコールでいいんじゃないの?
>>986 てあるからイコールじゃなくなくなくないなくない?
うん、そうだよ
どっちだよw
もうイコールでいいんじゃない?
そんないいかげんな
じゃあ、俺がイコールじゃないって事に決定した。
多数のサイレントマジョリティを考慮して 「イコール」 に決定させてもらいます。あたりまえの話だよね。
石田衣良乙