1 :
Name_Not_Found :
03/02/17 23:46 ID:PdNMca0f Strict な HTML(*) について語るスレッド ver.10
W3C 信者もそうじゃない人も投稿歓迎。
* 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) など。
過去ログ・関連スレ 及び 勧告等・その他
>>2-5
2 :
Name_Not_Found :03/02/17 23:47 ID:PdNMca0f
3 :
Name_Not_Found :03/02/17 23:47 ID:PdNMca0f
『 W3Cの仕様書をIEで見ようと思ったら、ダウンロードを要求された 』 IEが糞なので、どうしてもIEでみるなら… レジストリ弄ってtext/html追加汁。 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Accepted Documents ※自己責任で。
>IEが糞なので 失笑
1000おみごと
11 :
Name_Not_Found :03/02/18 19:41 ID:6CzovmoU
ありがとう
一瞬、ネタかと思った。<前スレの1000
しかしどんどん寂れていくね、ここも。 前々スレあたりのコテハンいたころが懐しい。
IEで見れねー物なんて淘汰されるだけ。 何考えてるのやら。
IEなんて使ってるやつはウイルスに犯されるだけ。 なに考えてるのやら。
[ツール]→[インターネット オプション]→[セキュリティ]→[このゾーンのセキュリティのレベル]を「高」
何も考えずにActiveX、Java、JavaScriptをオフ。 それから数分後。 やー、世の中って不便。
WindowsUpdateすると英語の世界にご招待。
Strict な HTML は IE で見れないのか。そうか。
そんなこたない
まあ、見られなかったことがあるんでしょうな。
XHTML1.1にやられたのですか
>>6 「 コンテントネゴシエーションで振り分けをしているので
xhmlに対応していないのに*/*を送るIEが糞なので 」
「html版を見るためには、レジストリ弄って」
xhml
>>24 つまらんからあげ足とる。
> xhmlに対応していないのに*/*を送る
IEにしてみれば「とにかく何でもいいからきぼんぬ」と言ってるだけ。
UAは何も全ての形式を自前で開けなきゃいけないわけではない。
このこと自体は全く問題ない。
問題は「text/html対応に関してAcceptで情報をよこさない」こと。
mhtmlはどうよ?
>>27 某マクロ html ですか。
香ばしいですね。
どうよって言われても。どうでもいいって感じ。
ネタ切れかな。 MHTMLは結局CSSと変わらんところが良かった(藁
まあ50スレまでに妙案が思いつかなかったんでしょ。
ああ、懐かしいね( ´ω`)
あれはネタだったの?
XML、XHTML、HTML、SGML、CSS、Strict, ・・・ もうなにがなんだかわかんないし、 IEでみれればいいじゃんって感じ。 オペラやネスケとか果てはドリカスまで すべてで見られるようにしてたらwebサイトなんて やってられない。 たとえばXHTML準拠のページ作ったって 全てのブラウザでちゃんとみれるわけじゃないんでしょ? W3C信者ってなんでそんなにがんばるの?
何が何だかわからないようなカスはリソースの無駄なのでとっととwebの利用をやめれ。
厨でもいい、もっと書き込んでくれ! 寂しすぎる。
ずんどこべろんちょうわわはっは うんこちんここここうんこ寛しねえええええええええええしね さんぷるねーし まんこkuseeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee どくおとこ息合点じゃねーよ(藁藁
スットリクトは凄いですか?
仕様に準拠していない文書を作ったって 全てのブラウザでちゃんとみれるわけじゃないでしょ?
むしろ準拠してない文章の方がいろんなUAで読める罠。 混沌とした変遷期なんだからアドホックに上手く立ち廻った者勝ち。
>>36 Strictに作れば、それなりに見られる。
ただ、XHTMLに関してはそもそも別物だからHTMLのために作られたUAで
正しく表示されることを求めるのは間違っているとは思う。
それでも、移行型のXHTMLならばそれなりに見られる。
だが、IE特化HTMLで作られたサイトは他のブラウザで表示できない事がある。
そこんとこ理解してるのかと問いたい。
最近Webサイト運営だかなんだかしらんが「やり」はじめたような香具師は、勉強してからモノを言え。
つーか、マルチポストしてる暇あったら、ポストマルチのキャラでも考えてろ。ボケが。
tableとfontとフレームを使うと決めた時点で互換性は捨てたと言える。
当方無料スペースにてwebサイトを営んでいます。 ちまたによくいるDQNのように広告ウザーなんてけして申しません。 むしろいかに広告をデザインのなかに溶け込ませるか、 という高いハードルに向かうことに多少の快感すら感じています。 ただ!! ソースが汚くなるのがイヤ!! <center></center>ってどーゆーことなのッ!! って私は重症でしょうか?
>>47 でも、そのだけのために有料スペースに移る気はないでしょ?
>>47 infoseekの</html>の後につく<div>〜</div>が激しく邪魔だね。
お前なめとんのかと。せめて</body>の直前にしとけと。
>>47 手動で広告入れられるとこを探せ。
XREA とか。
51 :
47 :03/02/19 22:43 ID:???
実は本サイトは有料のところなんですけど 2chのあるスレ関連のサイトが和鳥なんでございます。 XREAは手動で広告を入れればstrictにできるのは知ってたのですが 募集締め切っていまして…。 何がイヤって和鳥はstrictどころか<body>が勝手に大文字にされるんで xhtmlにすらできないことです。
かといってxhtmlにしたい理由も特にないんだろ
xhtmlにしたところで、application/xhtml+xmlとして扱ってくれるのだろうか。
>>52 痛いところをつかれた…。
はい実はxhtmlにしたからどうってわけではございません。
その和鳥のサイトは用語説明が多いサイトなんでxhtmlにすれば
将来自分で名前空間を定義して独自のタグを追加できたりして便利かな、
程度の認識しかございません。
あとは後々楽になるかなと。
無料スペースの広告部分もstrictなソースにすれば転送量も節約できて
エコロジーとか思うんですよねえ。
>>49 </html> の後の <div> なんて、別にどうでもいいんです。
<td><form></td><td></form><a></a></td> ってのをどうにかして下さい。
前は <a></a> がなかったから、無理矢理 valid にはできてたんですが、
現状では最早どうやっても無理です。終えてます。
こんなの、たとえ「タグ講座」の類のサイトであっても
「これは文法違反です」って解説されてるような奴じゃないですか。
おながいしますよ。マジで。
>>55 ></html> の後の <div> なんて、別にどうでもいいんです。
いや、文書要素が複数存在するってのは致命的な大問題だろ。
><td><form></td><td></form><a></a></td> ってのをどうにかして下さい。
寧ろこっちの方はSGMLなら狂ったmarkupに合わせて狂ったDTDを書くことで
解決が可能な予感(そんな狂ったDTD、でのvalidなんざSGMLパーサがエラーを
出なくなる以上のなんの意味も無いが)。
あと、そんな貴方にとりあえずここ推奨
http://www.strict.jp/ 一般利用者は募集してないが、正しいHTMLを愛するなら
入れてもらえるらしい。
>>54 後々楽になるっていってもさ、直接HTML書いてるわけじゃん?
んで XHTML2.0 が勧告になったらそっちを使いたくなるんでしょ?
んで手で書き直しと。全然楽じゃないし。
XSLT とかローカルで使えるんだからさ、オリジナルはXHTMLなり独自XMLなりでやってて
アップするときだけHTML4.01あたりにする程度でいいと思うんだけど。
XHTMLがもうすこし普及してこれば、変換ソフトも出てくると思う・・・
変換ソフトって…何に変換するのさ? 日記とかそんな程度のだったらバックエンドを改良したほうが スケーラビリティも高くて便利。
著者の利便性だけを考えるなら独自XMLをローカルでHTMLに変換で充分だが。 利用者がどんな使い方をしてるかなんて著者には解らない。 99.9%の利用形態がHTMLブラウザに表示しているだけだとしても 色々なUAで色々な使い方ができるように可能性は広く取っておきたい。 特にXHTML1.x系を導入する動機ってその辺じゃないかな。 対象UAにXML処理系も入れておきたいってのは変なことではないと思う。
ただ、"素"のXHTMLじゃ何も出来ないんじゃないかと思う。 利用しようにもRSSぐらい具体的じゃないと。 (想像力が足りないだけかもしれんけど。) 具体的じゃなくてもそれなりのルールに従って要素付けされてれば XSLTで変換して使いやすい形式に変換できるけどさ、 素のXHTMLの要素だけじゃ全然足りない。 なんでもかんでも dl に押し込められてたりするし。 だから、XHTML 使って再利用がうんぬんとかいうんだったら 別ネームスペース切って自分仕様のでいいから がんがん意味要素追加してほしいんだわ。 <div class="section"> とか <strong class="notice"> とかしないで <ex:section> とか <strong><ex:notice> ってしようよ。
>ただ、"素"のXHTMLじゃ何も出来ないんじゃないかと思う。 この辺が判断の分かれ目なんだろうね。 俺なんかは便利な使用法が自分で思いつかなくても XMLパーザ通らないよりは通る方がマシかなって思う。 ><ex:section> text/html のなんちゃって xhtml には無理ですたい。
変な質問なのですが、 <ul> <li><h3>あ</h3></li> <li>あいう</li> <li><h3>a</h3></li> <li>abc</li> </ul> こういう風に書いたとき、<h3>あ</h3>とか<h3>a</h3>は、何に対する見出しと言うことになるのでしょうか?
<h3>あ</h3>は<li>あいう</li>の、そして<li>a</li>は<li>abc</li>の見出しと考えても良いのでしょうか?
>>65 どんなDTDを前提にするかによっても変わってくるだろうけど、
ISO/IEC15445:2000なら
>>66 の解釈で良いと思われ。
ここで残念な話。
>>6 を実行すると、pdfなどが一部開けなくなるようです
(『ソースを表示』するとHTMLソースが出てきます)。
どうやらこの問題を解決するためには、
pdfのMIMEタイプをtext/htmlより先に持ってこないといけないようです。
コレについて何か知っていることがあれば、教えてください。
application/pdf を追加したら解決かな。 でも他にも副作用が出そうな予感。
IE6だと大丈夫じゃない?
ああ、safeじゃない、sageだ。
「副作用が出そう」なのに「安全」な分けないか(藁
>>73 IE6 (Not SP1)です。
>>75 そこにはDTDのURIを書く。
前者のURIはアクセスしても404ErrorでDTDは取得不可。
後者のURIならば実際にDTDが取得可能。
>>76 なるほど、そういうことですか。
どっちでもいいということですね?
返答どもです。
>>77 よくない。
前者のURIからはDTDが取得出来ない。
typical usage 通りに、後者のURIを指定しておきなさい。
>>78 了解しました。
典型的な使用方法(typical usageを調べました)通りに、後者を指定します。
rec-htmlの方は何のために、あるのですか?
rec-htmlを見たのは、W3Cの仕様書のURLなんですが、もしかしてrec-htmlと指定できるのは
W3Cに関連した企業・学校だけということなんでしょうか?
>>79 rec == Recommendation
>>84 落ち着け。
それはHTML 4.01の前の版、HTML 4.0が
出た時に示されたtypical usageだ。
今は
>>75 の下の奴を書いとけばそれでいい
(というかHTML 4.0は使うべきでない)。
今W3Cが推奨するHTMLのバージョンはXHTML 1.0なんだよな。 どうしてXHTML 1.1じゃないんだろう?
>>87 ネスケ4とか携帯(古い機種のみ?)とかだとid属性で
ページ内ジャンプができないからとか?
関係ないか。
>>87 XHTML 1.1 は HTML じゃないから。そんだけ。
XHTML 1.0 は一応 HTML と見なしても良いことになってるから、
「最新バージョンの HTML」ということになってるものと思われ。
text/htmlとして発信できる文書フォーマットの中で 最新のものがXHTML1.0と。
そゆこと
てーことは、1.0は読めても1.1を読めないブラウザがあるってことか?
(素の)Internet Explorer は IGNORE な空間内のパラメータ実体を 解釈しようとして下さるという大バグがあるので、XHTML 1.1 な文書を 読ませると Parsing Error となります。
1.0だって普通に書いてたらHTML処理系じゃ読めないことはいくらでもある。 HTML処理系でも読めるようにHTML互換の書き方だけで書いた1.0が 特別に text/html として認められている、ぐらいの感覚の方がよいかと。 # ある意味Transitional(移行期型)なんだよね、1.0って。
1.0はXMLとして機能するんですか
汎用性のある日記CGIを組みたいのですが、どのようにマークアップするのが適切なのでしょうか。 CGIで生成するものは ・過去ログへのリンク ・見出し ・日付 ・本文 です。 %lt;body> <h1>日記のタイトル</h1> <div class="navigation">リンク</div> <div class="day"> <h2>見出し</h2> <div class="date">日付</date> <div class="sentence">本文</div> </div> これだとdiv房っていわれちゃいますかね。
それらのdivの中には適切なブロック要素が入るんでしょ? ならdiv厨じゃないよ。
100 :
98 :03/02/21 21:01 ID:???
なんかタイプミスしてますた。吊ってきます。
>>99 氏
ブロック要素がはいるかどうかは使う人に依りますね。
HTMLをほとんど知らない人は「本文」にそのまま文章書いちゃいますし。
それじゃ<p>本文</p>にすればいいんじゃないかとも思いますが、
人によっては「本文」に
「文章<pre>文章</pre>文章」
のように書く人もいるでしょうし。
あと、リンクと日付のところにはブロック要素が入らないです。
リンクはlistにしてもよかったんですが、navigationの目的にあわなそうなので、単純にdivとspanの組み合わせで行きたいと思っています。
日付の方は<p>日付</p>のようにするとなんだかしっくりこないのでdivにしてみますた。
ノジたんはdtとddを使ってるようですが実際のところどうなんでしょうかねぇ。
何か定型的というかもっとよい方法があればご教授願いたいのですが。
>>100 <div class="navigation">リンク</div>
というのは日記の内容になっているの?
h1レベルの内容として相応しいかどうか要再検討。
>>100 実際の内容がどんな感じなのか
分からないけど、
・リンクはul
・日付はdl
・本文はp
・div.dayはそのまま
でどうか。
104 :
98 :03/02/21 21:44 ID:???
>>101 氏
リンクはhome、index、ログなどナビゲーション用のリンクをまとめたものです。
h1レベルといわれると、怪しいですね。
>>102 氏
ぐ、やっぱり・・・
>>103 氏
やはりそのような感じになるのでしょうか。
具体的には
<h1>strictじゃない日記</h1>
<ul>
<li><a>HOME</a></li><li><a>Index</a></li><li><a>13月の日記</a></li>
</ul>
<div class="day">
<h2>マスターキーの呪い</h2>
<dl>3002/14/20</dl>
<dt><p>
韓国のあの香具師は末代まで祟られるのだろうか?<pre>以下略</pre>ようするにイッテヨシ。
</p></dt>
</div>
<div class="day"></div>
・・・
こんな感じですか。
cssをオフにするとulの部分が占める割合が大きいような気がしないでもないです。
そのdlはなんだ
103が言ってるのは <h1>strictじゃない日記</h1> <ul> <li><a>HOME</a></li> <li><a>Index</a></li> <li><a>13月の日記</a></li> </ul> <div class="day"> <h2>マスターキーの呪い</h2> <dl> <dt>Date:</dt> <dd>3002/14/20</dd> </dl> <p> 韓国のあの香具師は末代まで祟られるのだろうか?(以下略)ようするにイッテヨシ。 </p> </div> ってことじゃないの。
<div>日付</div> と書く位なら、 <p>日付</p> と書いた方が数段まし。 ……だと思う。 いや、DTD的にはアリなんだろうけど、 個人的には、<div>の真下にベタテキストが現れる、というのはもの凄く気持ち悪い。
>>105 >>106 氏
・・・。
<dl>
<dt>2005/04/32</dt>
<dd><p>話は変わるが最近の若者は(以下略</p></dd>
</dl>
ですね。申し訳ない。
110 :
98 :03/02/21 22:00 ID:???
>>107 氏
あ。そういうことだったんですか。勘違いしてますた。
ノジたんのソースが頭に焼きついてしまって。
>>108 氏
そうですか。日付って微妙に扱いにくいんですよね。divよりpのほうが良いですか。
オリジナルのデータがHTMLだけになるんだったら、 適当なclass名でも振っておかないと変換が面倒かもね。
>>110 適切にクラスを割り振るんであればdivでもpでもどっちでもいい。
>>108 自信も言っているがはただの好き嫌いの問題だから。
div直下にどうしてインライン要素が置けるかを
考えられるようになったらまた来いよ。
てか <div> 直下にインラインはイクナイって誰が言い出したの?
神崎さん
レナの人とか。うろ覚えなんで違うかもしらん。
117 :
98 :03/02/21 22:25 ID:???
>>111 氏
そうなんですよね。変換のことを考えるといっそのことXMLにしようかとも考えたのですが、やはりHTMLのほうがなにかと便利なので。
>>112 氏
意味ですか。divはクラスやIDと併用してグルーピングの用途に用いる。
XMLのタグのようにHTMLで定義されていない要素をマークアップするのに使える。
のように押さえていますが、どうなんでしょう。
オブジェクト指向チックに考えるとしっくりくるかもしれん。 そういう意味では div 直下にインラインがくるのはなにもおかしくないような。
div直下にインラインがイクナイ! とは余り聞かない話。 ただし、今後同じdiv内にブロック要素が書かれるばあい、現在の 直下インライン要素が匿名ブロックかする恐れがあるので、 そのような場合、適切なブロック要素を1段かましたほうがいい、って話。 ちなみに、すみけんさんが、liの内容を例にあげてどっかで解説してたはず。
お次は匿名ブロックネタですか。
次インデントの話題↓
ttp://pc2.2ch.net/test/read.cgi/hp/1044669039/l50 で、出た話題なんですが、
>p>の場合最初に空白をいれるのかtext-indentで指定すればいいのか、、、
>欧文作法なら空けないでしょといわれてもしっくりこない。
>「?」「!」の後を1マス空白にするのも同じ理屈で。
>(text-indentを使う場合↑の時はどうするんだろう? 空けないのかな)
どうなんでしょうか?
あと、CSSでtext-indentした場合、セリフから始まる段落もインデントされてしまいますが、どう対処すればいいんでしょうか?
ぶろっこーとでインデント作ってもおっけー ソース見んなぼけ
124 :
122 :03/02/22 05:10 ID:???
125 :
122 :03/02/22 05:12 ID:???
うわ、読み返したら分かりにくいかも。
>>122 は、段落の最初のインデント、についてです。
126 :
121 :03/02/22 05:12 ID:???
>>122 CSS も HTML も出来ないことは山ほどある。
少なくとも現在はそういうものだと諦めるしかないと思われ。
>>122 >あと、CSSでtext-indentした場合、セリフから始まる段落もインデントされてしまいますが、どう対処すればいいんでしょうか?
セリフにはセリフとわかる class を振って、そこだけインデント解除すりゃいーじゃない。
>>128 しかし、小説とかだと果てしなく面倒くさい作業になるな
>>130 置換ソフト使って、
<p>「
↓
<p class="speech">「
とかにすれば楽じゃない?
>>130 <p class="speech">なら括弧もquoteにしてしまえ! といってみるテスト。
おれは、そんな面倒くさい事絶対にいやだw
ぽまいらヘッダにちゃんと文章の関係を記述してますか。 HELPやCOPYRIGHTのページは用意してますか? っていうかOpera7の新機能はどうよ。
135 :
131 :03/02/22 13:16 ID:???
>>132 俺に言えよ。
というか、そう言えばそうなんだが、
CSS対応
行頭にインデント、セリフにはインデントなし。
CSS未対応
行頭にインデントなし、セリフにもインデントなし。
だけど、
<q>については【「】をレンダリングしてくれないのもあるからな。
>133 122でキシュツだよ
137 :
132 :03/02/22 14:12 ID:???
>>135 スマン、間違えた。
>だけど、
><q>については【「】をレンダリングしてくれないのもあるからな。
台詞は引用じゃないし、レタリングしてくれないかも
ってんならCSSそのものがつかえないし。
バランスってのがあってどこまで採用するか、しないかって話であるが
>>137 しかし、セリフは引用符で括られてる、ってのがややこしいんだよな。
鍵括弧自体の意味が変化してってる(強調で使われたり)しな。
> 台詞は引用じゃないし、レタリングしてくれないかも
> ってんならCSSそのものがつかえないし。
いや、だから、レンダリングしてくれなくても文意は変わらない(インデントとか)ってのとは違うじゃん、って話。
139 :
132 :03/02/22 15:02 ID:???
ぶっちゃけると、HTML文書において文意はmarkupでしめされるって事に なってるからレタリングは気にすんな、というのが解答になるわけだが…、 class+cssの場合、HTMLの公約数的要素に入ってないからそれを前提として 期待するのはどうか、といわれれば確かにその通り。
⇒ レタリング [lettering<letter (文字) ]文字によるデザイン. 文字を書くこと, 文字で表現すること, またその技術.〈現〉 ⇒ レンダリング【rendering】 (デザイン・建築関係で)完成を予想して描いた透視図。完成想像図。
142 :
139 :03/02/22 15:22 ID:???
指摘感謝。今度から直します。
CSS無効な環境ではqやciteに鍵括弧が表示されないこと自体はいいんだけど、 qやciteではないのに鍵括弧が使われる箇所(会話文や、出典ではない書名など) との整合性がとれないのが嫌で、CSSのquotesプロパティを活用するのをやめ、 素のテキストに鍵括弧を書くように改めた。 通常、鍵括弧が登場する箇所には、すべて <p class="conversation">こんばんは</p> とか <p><span class="book-title">吾輩は猫である</span>を買いました。</p> といった風に適当なclass名をつければ、素のテキストから鍵括弧をすべて 排除することができ、整合性はあることになるけれど、そこまでやる メリットが原理主義者の自己満足以外にあるだろうか。
144 :
143 :03/02/22 18:01 ID:???
会話文の見栄えをすべてCSSで制御するには、もうひとつ問題がある。 「句点と鍵括弧が連続する場合は句点が消去される」という法則を緻密に 再現しようとすると、すべての文章から句点を排除し、 p:after { content : "。"; } p.conversation:before { content : open-quote; } p.conversation:after { content : close-quote; } p.conversation { quotes "「" "」" "『" "』" } などとやらなければいけなくなる。 やはり、CSSで鍵括弧の表示を制御しようというのは、あまり現実的ではない と思う。
>「句点と鍵括弧が連続する場合は句点が消去される」 へぇ、今はそういう法則なんだ。時代だなあ。 漏れが小学校の時は 「句点と閉じカギカッコを一つのマス目にまとめて書く」 というスタイルですた。 CSSは日本語の組版慣習なんかほぼ未サポート。良く言ってこれから。 そんな技術でどうにかごまかしぬくために 文書を変にいじりまわすことないと思う。
>>143 今の話の流れから逸れるし、殆どmarkupするものの好みと言えるが、
><span class="book-title">吾輩は猫である</span>
このspanはemのほうがこのましくないだろうか。
本のタイトルだから括弧がつくのか、強調したいものが本のタイトルなので
括弧がつくのか。
>>145 漏れもそのように小学校で習いました。ちなみに昭和50年生まれ。
あと、全般的に、原稿用紙の文法に拘る必要は全く無い。例えば段落の行頭を
1字下げるのは原稿用紙における段落開始の明示法つまり、HTMLにおけるp要素
でのmarkupに相当するもので、CSSで原稿用紙の表示を再現する必要は無い。
#勿論一般的に広く知れ渡ったスタイルとして採用する価値は高いと思う。
従ってCSSによる自由なスタイル指定が可能な状態で「原稿用紙の再現」を
高いプライオリティーに設定「しなくてもいい」のでは、と思うが、どうか。
英文だと空白文字でインデントできないから、 CSSにtext-indentプロパティが設定されたんだろうな。
>>144-146 句点は文の終わりを意味し、"」"は会話の終わりを意味する記号。
教科書等では"。」"と表記するのが本来の形。
しかし、"」"があることにより、文の終わりであることは分かるので
省略しても意味は通じる。
小説等では作者の表現の自由による。
新聞・雑誌等では字数を減らすために句点は省略する。
国語審議会では、かぎかっこと句点の書き方について特には決めていない。
(2001年2月15日 PHP文庫発行 "読売新聞大阪編集局 雑学新聞"より)
ちなみに昭和55年生まれだけど小学校では
>>145 のように習いました。
・・・学校教育はずっと変わってないのか。
俺もそう習ったが"」"の前に句点は書かない 多分、読む本読む本みんなそうだったから
仕事先では」の前には句読点を使わない用字をするように言われてた。 某通信社で採用している規則をそのまま借りてきたらしい。
句点。 読点、
155 :
Name_Not_Found :03/02/23 10:39 ID:0QY8ajxn
Strict日本語ですか?
日本語審議会です。
%5F
159 :
143 :03/02/23 12:49 ID:???
あー、意外なところで反響が。
俺は昭和47年生まれだけど、学校では、
>>145 と同様に、
「こんにちは。」
と書くように指導された。
たぶん今でもそうなんじゃないかな。(
>>150 は中1?)
しかし、小説をはじめ、商業出版物では、
>>152 も言うとおり、
「こんにちは」
と書くところがほとんど。
役所などの公的な文書ではどうなってるかわからないけど。
そもそも公的な文書にはあまり「会話文」って出てこないだろうし。
>>145-146 まあ、こだわるべきところではないね、たしかに。
>>159 普通は括弧の中にも句読点をうつけど、
ごく短文の場合は省略してもよい
…と国語辞典の後ろに書いてあったよ
>155 strictなhtmlを意図した通りに機能させるには、正しい日本語が必要です。つまり、正当(valid)な日本語と共に、strictなhtmlを用いる必要があります。
↓のじたん
163 :
157 :03/02/23 14:04 ID:???
>>163 なんて怒られたの?
/* lintの結果にリンク張ったら、lintに怒られたよ。実態参照で回避したけど */
165 :
157 :03/02/23 14:17 ID:???
166 :
157 :03/02/23 14:44 ID:???
というかスレ違いの予感がしないでもないですが >ホスト名は英数字とハイフンから成る文字列(ハイフンは先頭や末尾には来ません)をピリオドで繋げたものです。 下線などは使えないことになっています。 となっているのになぜ fake_Funiv.tripod.ac.jp みたいなホスト名が存在するのでせうか。
>>166 あー、俺もそれちょっと疑問だったな。
まあ、規格に逸れたのも容認されてる→でも、規格外、といったところなんだろうけど。
また別の結果の解説からの引用なんだけど、216の、
>つまり、< や > などはURIに使えない文字なので、< や > などもURIには使えません。
と似たような理由は考えられないかな?ちょっと自信ないけど。
169 :
157 :03/02/23 16:08 ID:???
>>167 >>168 ようするに、現状では規格外な記述も許されていて、
このようなURIにリンクを貼る場合にはlintで減点されても仕方がないということですね。
あありがとうございました。
もしそのURLがtripodのものなら members.tripod.co.jp/fake_univ/ というURLにすれば回避できる。 ついでに管理人さんにsquid経由で読めないから ショートURLは使わないでくださいとメールしておけ。
>>170 ついでにTripodに文句入れておいたらどうだろう?
invalidなものを弾かないのは問題だろうし。
>>170 >>171 いや、実際は鳥さんではないのですが。
管理人さんや鳥さんにメールでゴルァは漏れには恐くてできませぬ。
じゃ折れがやる メアド晒せ
質問です。 2月13日に、彼女から<q>別れて欲しい</q>と言われた。 という文があるとすると、<cite></cite>はどこへマークアップす? やっぱ“彼女”ですかね?
>>174 <q>別れて欲しい</q>……<cite>2月13日の彼女の言葉</cite>だ。
文章は変えられないんです。 それで悩んでるんです・・・
2月13日に、彼女から「別れて欲しい」と言われた。 でいい。qもciteもマークアップしなくていいだろ。
>>176 日本語にも主語のない(省略された)文とかけっこうあるでしょ。
それと同じで、この文にはciteに相当する要素はないので、無理してciteにできそうな部分を探すのは本末転倒。
何のためにマークアップするのかよーーく考えてよね。
180 :
Name_Not_Found :03/02/24 03:44 ID:60Ve66IO
♂ オス 雄を表す記号 この場合「オス」を記号の読み方として<dd>にすべきなんでしょうか それとも説明されるものの名前として<dt>とすべきなんでしょうか
>>180 <dl>
<dt>♂ </dt>
<dd>オス</dd>
<dd>雄を表す記号</dd>
「雄を表す記号」は、「オス」の説明ではない。
「オス」は、「♂」の説明(読み方)に当たる。
</dl>
183 :
Name_Not_Found :03/02/24 04:07 ID:60Ve66IO
184 :
Name_Not_Found :03/02/24 04:55 ID:4iML4KuH
>>185 dl直下に生テキストが来てるのでエラー
187 :
185 :03/02/24 09:36 ID:???
>>186 慌ててフォローしたつもりだけど生テキストはどうにもならないよなあ。ごめん。
classとidを同時に使うのは思想的に正しいのでしょうか。 例えばこういう場合です。 同一ページ内で、ある事柄について、男の場合、女の場合それぞれについて 解説するようなときです。 男の場合の解説、女の場合の解説について、それぞれ<div class="explain">と して共通スタイルを適用した上で、男の場合の解説と女の場合の解説の 背景を違うものにしたいときに、それぞれ<div class="explain" id="male">、 <div class="explain" id="female">とする感じです。 もちろんクラスにして<div class="explain male">とかにしてもいいのでしょうが、 サイトの発想的に、そのページ内では1回しか出てこないのでidの方がいいのかなと。
>>189 そんな面倒なことをするんなら、
#male,#female{
内容
}
共通する部分はこうすればいいんじゃねえの?
なるほど、そういうのも大いにありですね。 なんでこんな一見面倒なやり方なのかというと、 189の"explain"を男女の解説とは関係ない、他の ページの解説でも使うからです。 つまり、男女の解説でなくても、とにかく解説部分には "explain"を使っているんです。
>>191 document unique なものに対して id を指定するのは、むしろ当然だし
class と id を同時に使ってはならないという「思想」なんて聞いたこともないんだが…
今は良くても、将来のページ更新で再び男女を比較した解説が追加されないとも限らないので
自分なら両方とも class にするけど…
確かにそうですね。絶対しないと思っていて結局後からやってる事など 今まで数え切れないぐらいありますから、classの方がいいかもしれません。 さらに検討してみたいと思います。 idで定義したスタイルというのは要するに「そのスタイルに関しては ドキュメントユニークである」と言っているにすぎないから、それにプラス してclassを指定しようが、別にid側としては関知しない、ということだと 思うので、同時に指定しても別に何もマズイことはなさそうですね。 やってみたのですが、ブラウザではIEもNNもOperaも意図通りには表現 できました。
IDって、「一つの文書に複数出てきてはいけない」のであって、 「サイト内に複数出てきてはいけない」ではないですよね?
うん
掲示板のスクリプトが出力するHTMLを正しく直して下さいって言うのはありですか?
199 :
197 :03/02/25 00:53 ID:???
誤爆です。
スクリプト配布元次第
その前に、StrictなHTMLを出力するスクリプトがあると思うのだが。 いくつか見かけた記憶があるよ。
>>171 おそらくユーザーIDの変更を伴うから難しい罠
iswebに統合されるとき「-」に変更になると思うので
とりあえず放置してる
>>203 いや、新規登録がなくなるだけでもな、とね。
けっこうそれが原因でつなげない人って居るようだから。
無力な人間が息巻いてる様って……笑える
FAQとかに定義リストを使ってもいいの?
100 名前: 名無しさん 投稿日: 2003/02/26 11:11 ↑こういうのって見出し? そんな深く考えんでいいんかなあ。
>207 FAQって表で書くもの?
>>208 見出しじゃないんじゃないかと。
適当にクラス振って構成要素を分割しとけば再利用とやらもできるかもね。
<span class="no">100</span>
<dl>
<dt>名前</dt>
<dd>名無しさん</dd>
<dt>投稿日</dt>
<dd>2003/02/26 11:11</dd>
</dl>
こんなのよか
<messages>
..
<message abone="true" />
<message author="名無しさん" date="2003-02-026T11:11+09:00">
ほげほげ
</message>
..
</messages>
こういうのの方がよっぽど再利用できると思うけどな。
>>209 dt 使った場合、dt 部分が Question になるんだろうけど
Question 部分もブロックレベル要素使ったりしない?
ペアになるものを記述する要素は現在の HTML には無いと思う。
dt にはあくまで term を書くべきでしょう。
question と answer のペアを div で括るぐらいが妥当だと思う。
<div class="faq pair">
<div class="question">
<p>W3Cの仕様書がIEで見れないんですが?</p>
<p>IEが糞なんですか?</p>
</div>
<div class="answer">
<p>レジストリ弄ってtext/html追加汁。</p>
<pre>...</pre>
</div>
</div>
>>211 どういうのを要素にすべきでどういうのを属性にすべきかっていう判断って
どこでくだしたらいいんだろ?
214 :
Name_Not_Found :03/02/26 19:56 ID:p54ESHSd
>>212 Div病の様に見えてしまったよ・・。
それに、それじゃCSSを切った時に何がなんだかさっぱり解らない。
CSS 切った時うんぬんって実際どうでもいい話じゃない? 結局見た目に拘ってるのと一緒でさ。 表現したいことに相当する要素がなかったら 既存の要素を変な解釈して使うより div に class 付けて使うべきでしょ。 CSS 使えない UA そろそろどうにかしてくれってかんじだな。 "CSS切った時"なんて見た目のこと考えなくてすむようになるし。 HTML では純然たる文章内容だけ考えて記述出来るようにするべきだ。 扱える media の種類もあんだけあるんだしもういいだろ。
CSS 切った時は *デフォルトのスタイルシート* が適用されるんだよ 妙な話だよね
w3m だの lynx あたりでもせめて display: inline ぐらい使えれば かなり違ってくると思うんだけどなぁ。
>>215 貴方様のお作りになられるCSSのデザインが一番素敵というわけではありませんの。
ユーザスタイルシートは何の為にあるの?
ブラウザが最初からイケてるCSSを用意してくれればいいんだよ
馬鹿かおまえら。 イケてないオナニーCSSなんかよりデフォルトスタイルシートのほうが ずっと見やすい。
>>218-
>>221 多分
>>215 はイケてるイケてないの話をしてるんじゃなくて、
通じる通じないの話をしてるんだと思うけど。
>>212 みたいなソースだったら content プロパティとかに関しては
「特定のスタイル」を適用させないと意味が通じなくなっちゃうもん。
.question:before{content:"質問:";} とかね。
要は、文書構造を変化させるスタイルシート
(XSLT 全般/CSS の内容追加)の利用を前提に、
HTML の汎用性を若干犠牲にしてもいいんじゃないかって話では。
text/html じゃなく application/xml として使うというか。
>>222 君はひょっとして<p class="waring">警告!</p>とかを認めるタイプ?
>>222 つまりHTML単独で機能させようとするのは無理があるだろう、と。
> .question:before{content:"質問:";}
好みの問題だが、漏れなら
title="質問" にしといて content:attr(title) にするなとか思った。
てかXSLTを前提にする場合って出力結果がHTMLなら
結局みなさん同じことで悩むんじゃないの?その点禿しく疑問なんだが。
>表現したいことに相当する要素がなかったら >既存の要素を変な解釈して使うより div に class 付けて使うべきでしょ。 つーのには同意。 あと、CSSは所詮はスタイルを変更するものであってHTMLの文書構造を 変化させるもの(例えばDOMとかXSLとか)とは訳が違うから単独HTML として意味が通じない文書構造ってのは確かに問題。 特にXHTMLの文書はさらにXSLTで別のHTMLとかに変換される場合があり、 この場合CSSとかと完璧に独立した単独XHTML(というかXML)文書として 評価される訳で。
やっぱり HTML は レンダリング のためだけに存在するんだよ。 非視覚系メディアのケースもレンダリングに含むとしてね。 レンダリング上有用だと思われるものに対してだけ コンセンサスとっときゃいいんだよ。
>>225 class に question が入ってる時点で意味が通じてるってことにはならない?
事前に"class に question が入ってたら質問である"って決めてあることが
前提だけど。
"名前: " とか "日付: " っていう文字列自体は
文章の本質的な構成要素じゃないと思うんだ。
だから文章中に直接あらわれる必要ってないんじゃないかなぁと。
逆にそれが本質的な意味を持つなら contentで定義してはいかんということだ
何をもって本質的とするかだよね。 FAQデータ本体としてなら、"質問:" とかは不要だけど 一介の文章としてなら必要だろうし。 HTML レベルで書くなら CDATA だけ拾って読んで意味がわかるようにするってぐらいが 丁度いいのかもしれない。
Strict-*HTML*スレなのにどうしてXML絡みの話題で盛り上りますか。
No.1 ●●●(名称) 画像(ある場合はココに) これについての説明・コメントなど。 No.2 ●●●(名称) 画像(ある場合はココに) これについての説明・コメントなど。 No.3 ●●●(名称) 画像(ある場合はココに) これについての説明・コメントなど。 こういう感じでランキングのページを作りたいのですが、この場合は <dl> <dt>No.1 ●●●(名称)</dt> <dd>画像(ある場合は)</dd> <dd>これについての説明・コメントなど。</dd> <dt>No.2 ●●●(名称)</dt> <dd>画像(ある場合は)</dd> <dd>これについての説明・コメントなど。</dd> <dt>No.3 ●●●(名称)</dt> <dd>画像(ある場合は)</dd> <dd>これについての説明・コメントなど。</dd> </dl> こんな感じでいいのでしょうか?
>>231 オイスターがイパーイ。じゃなくて、
OLで順番を示すべきではなかろうか。
No.1と出したいならスタイルシートで。
この場合"No.1"を示すことが重要だからスタイルシート任せはイクナイってのが ここ最近の流れじゃないの?
>>233 「1」と「No.1」の違いにそれだけの意味があるならな。
>>234 そういう意味じゃなく、"1位"であることに意味があるわけじゃん?
ol はただ順番に並んでるってこと示すだけで
1位であるってことは示してくれないと思うんだが。
>>235 じゃあol且つliにclass指定で、スタイルシートでliのマーカーを消しなされ
>>235 >>234 は、
No.1ってのは特別な意味(偉さとか)がある場合と、「一つ目の項目ですよ」を強調してるだけの場合がある、って意味。
その重要度によって変わるんじゃないか?って事だよ。「意味」を「マークアップ」するわけだし。
>>237 「ランキング」という以上、単なる「一つ目の項目」という意味を超えていると
思うのですがどうでしょう?しかしそれをいうと、2つ目にも「2位」という
意味があり、3位も同様……以下繰り返すと、結局全部意味持ってしまうことに
なりかねないような。
常識的に3位ぐらいまでが妥当なのかな。
ナビゲートバーは、pかdivどちらがいいですか?
<ol> <li>を使ったときに出てくるアラビア数字は使うべきではないですか?
>>242 1.2.3.、一.ニ.三.い.ろ.は.など何になるか
ブラウザによって違いますが、CSSで、decimalと指定すれば言いだけですから、
使ってもいいです。
上にもあったように、 ランキングを作る場合のol liは、CSSで数字を消し、 <ol> <li>1位 あさん</li> <li>2位 いさん</li> </ol> とするべきです。
「天皇の地位は、国民の総意による」 の「地位」と「総意」の意味を別のところに写したい場合は、 <p>天皇の地位(*1)は、国民の総意(*1)による</p> <ol> <li>*1 [地位] 社会や組織などの中での、その人の置かれている位置、立場。</li> <li>*2 [総意] 全ての人の意見。</li> </ol> とし、CSSで、 ol li {list-style-type:none;} とするといいですよ。
<p>天皇の<dfn>地位</dfn>(<cite>*1</cite>)は、国民の<dfn>総意</dfn>(<cite>*1</cite>)による</p> のほうがいいかな。
<p>天皇の<a href="#d1">地位(*1)</a>は、国民の<a href="d2">総意(*2)</a>による <dl> <dt id="d1">*1 地位 <dd>社会や組織などの中での、その人の置かれている位置、立場。</li> <dt id="d2">*2 総意 <dd>全ての人の意見。 </dl> CSS未対応環境下での印刷を考慮するとこうかな。
<ol> <li> <dl> <dt id="d1">*1 地位 <dd>社会や組織などの中での、その人の置かれている位置、立場。</li> </dl> </li> <li> <dl> <dt id="d2">*2 総意 <dd>全ての人の意見。 </dl> </li> </ol>
確かに、用語の解説の順序には、意味があるけど、
>>248 のように記述するのは、面倒だよね。
「地位」と「総意」の間に前後関係があるとは思えない。
>>239 おそらく情報の構造から考えればリストなどの要素で表現できるはず
それからCSSを使って"ナビゲートバー"なるものを作るのが妥当では?
「天皇の地位は、国民の総意による。」 これが、憲法の条文で、地位、と総意の意味をつけるなら、 <p>天皇の地位<ins>(*)</ins>は、国民の総意<ins>(*)</ins>による。</p>
253 :
231 :03/02/27 12:14 ID:???
ol liを使って且つCSSで数字を消す場合、画像や説明なんかにはclass=gazou class=commentなどの ようにそれぞれのliにclassを割り振ってあげればいいのですか?
<p>天皇の<a href="#d1">地位(*1)</a>は、国民の<a href="d2">総意(*2)</a>による <dl> <dt id="d1">*1 地位</dt> <dd>社会や組織などの中での、その人の置かれている位置、立場。</dd> <dt id="d2">*2 総意</dt> <dd>全ての人の意見。</dd> </dl>
dl 中途半端だよなぁ。dt+ dd+ にしてくれよう。
dl直下にdt,dd要素しか配置できないってのが終わってる このせいでレイアウトに不便ありすぎ
このスレおもろい。
>208 <ol> <li> <dl> <dt>名前</dt><dd>名無しさん</dd> <dt>投稿日</dt><dd>2003/02/26 11:11</dd> <p>投稿文</p> </dl> </li> </ol> こんなのは?
<ol><li> いらん。
ナンバーは何になるの?
ナンバーナンバーナンバー
>>259-260 <ol>
<li>
<dl>
<dt>名前</dt><dd>名無しさん</dd>
<dt>投稿日</dt><dd>2003/02/26 11:11</dd>
<p>投稿文</p>
</dl>
</li>
<li>
<dl>
<dt>名前</dt><dd>名無しさん</dd>
<dt>投稿日</dt><dd>2003/02/26 11:11</dd>
<p>投稿文</p>
</dl>
</li>
</ol>
で、レス順まで包含してるんだろ、きっと。
俺もこれでいいと思うぞ。
>>262 <dl>内に直接<p>を置くことはできまへんでおまんねん
<p>投稿文</p> ↓ <dt>投稿文</dt><dd><p>こうかな?</p><dd>
最後のddミスった…
<ol> <li> <dl> <dt>名前</dt><dd>名無しさん</dd> <dt>投稿日</dt><dd>2003/02/26 11:11</dd> </dl> <p>投稿文</p> </li> </ol> これでいいじゃん
>>241 <div>直下に生テキストが出てくるということ?
それはちょっとなぁ。
divを使った場合、classなどで意味付けを施したとしても、それはレンダリングの際
参考にされるだけであって、(視覚系UA以外も含めた)パーザの立場からすれば
divはただの意味のないブロック要素と理解される。
意味のないdivはパーザにとっては取っ払っても同じことだから
その下に生テキストが出てくるのは(文法的にはOKでも)何か気持ち悪い。
<p>に<object>をかませばその下に<ul>を文法的には置けるけど気持ち悪い、
というのと同じように気持ち悪い。
# この辺は、意見がかなり割れるところだと思うけど。
あと、pの“段落”はかなり広い意味にとってもいいんじゃないかと個人的には思う。
W3Cのドキュメントでも、W3Cのアイコンだけの“段落”というのがあるし。
>表現したいことに相当する要素がなかったら >既存の要素を変な解釈して使うより div に class 付けて使うべきでしょ。
>>267 あら。本当にバナーだけを p でマークアップしてるところがあるね。
ふと、日本語の「段落」と英語の「paragraph」は必ずしも同じ意味では
ないのではないだろうかと思った。
「段落」というと、ある程度まとまった意味を持つ文の集まりしか指さない
けれど、「paragraph」はもっと違うものも指すのかもしれない、と。
仕様書は英語のみが正式だったよね、確か。
もっともこれはネイティブの人に訊かなければわからないことだけれどね。
>>269 「ちょっとしたニュース記事」っていう意味もあるみたい
曖昧すぎてわけわかめ
>>267 じゃあ何のために、divは内容にPCDATAを含むことが出来るのか。
W3Cの仕様書は説明不足。
なんも考えてなかった頃はdlなんてまったく使わなかったのに 「正しいHTML」を意識するようになって dlを多用せざるをえなくなってしまった なんかバランスわりー
( ゚д゚)
276 :
271 :03/02/28 02:19 ID:???
>>274 リンク先は、生テキストとブロック要素の混在について言及しているが、
それは私の求める答ではない。
私が聞きたいのは、
divが生テキストを含むことを非としたときに、
PCDATAを含めるという仕様をどう解釈するのかという事です。
>divが生テキストを含むことを非としたとき 非としない、でFA。従って >PCDATAを含めるという仕様をどう解釈するのかという事です。 と言う問題も発生しない。
css厨は世界中の人間が一人残らずIEを使っているという妄想を抱いているんですね
>>267 > 意味のないdivはパーザにとっては取っ払っても同じことだから
なんでそうなっちゃうのか説明きぼんぬ。意味が不明でも構造は残る。
lang とか title とか属性つくものが取っ払って同じわけない。
際限なく拡大解釈された p に div を超える意味があるとも思えない。
少なくとも div にすれば「段落や見出しやリストとは別の何か」という
意味を付すことができると思うが。
>>278 逆だろ……どんな環境でも利用できなければならないという妄執にとらわれてるんだよ
むしろIEがなくなることを願って止みませんが
Strict厨の「どんな環境」にはIEが含まれないの法則ですね
IEに限らずクソUAは基本的に対象外かと。
むしろスタイルシートを適用させない方向で。
まあ、あれだ。 table 使うのやめたところで安心してはいけない。 dl 多用しだしたらちょっと危ないな…って思ったほうがいい。 また別の種類の厨になりかけてることは確かだ。 まともに書いたところで再利用なんてどうせしないし出来ないんだから どんな書き方したって関係ないっていや関係ないんだけどな。
あははは。 HTML を誤解するのもいけないが、過大評価するのもいけないよな。 まあ再利用についてはメインターゲットは 未来の予測できない環境の自分自身だと俺は思ってるが。
んで、未来になって使おうとしたら 要素の分類の粒度が荒すぎて結局使いものにならないという罠。
今、FAQを作っています。 質問と、回答にはdlを使うことにしたのですが、 回答(dd)の中にdlやHnなどブロック要素を含むことができます。 <h1>FAQ</h1> <h2>hogeについて</h2> <dl> <dt>hogeを使うとどうですか?</dt> <dd> こんな感じです。 <h◆>メリット</h◆> <ol><li>癒される</li><li>うれしい</li></ol> : </dd> このとき、◆は3ですか?
<dl> <dt>メリット</dt> <dd>癒される</dd><dd>うれしい</dd> </dl> の方が。
再利用する気があるならXML版を別途用意した方がはるかに効率がいい罠。
>>267 ,
>>271 ,
>>276 div 直下にテキスト/インラインだけを記述する分には問題ないと思うけど。
例えば HTML 4.01 で h7 相当の要素をマークアップするとしたら、
<div class="h7">foo</div> とでもするのが適切だと思うし。
>>291 でも実際、圧倒的チェア(藁)を持つ
IEを考えて html版を作らないといけないんですよ。
で、そこで詰まっているわけで。
>>290 <dl>
<dt>〜</dt>
<dd>
<dl>
<dt></dt>
<dd></dd>
ですか。ありがとう。
でもHnを使うなら順番的に3かなぁ。
>>292 > 例えば HTML 4.01 で h7 相当の要素をマークアップするとしたら、
> <div class="h7">foo</div> とでもするのが適切だと思うし。
div直下のテキスト云々という話とは別に、その場合は文書を分割して
見出しのレベルを少なくする方が適切だと思うが。
行き当たりばったりはダメですよ。
3だよ。
>>289 <h3>hogeを使うとどうですか?</h3>
<p>こんな感じです。</p>
<dl>
<dt>メリット</dt>
<dd>以下略</dd>
</dl>
h3使うならこんな感じのがいいんじゃないか
>>291 まあ、XML版作ってもどうせ下位互換の為XSLTあたりでHTMLにするわけで。
んで同じようなことで悩むのさ。
>>299 どうせ下位互換の対象になるようなUAはHTMLの有効な再利用なんかできない。
一般閲覧用は妥協満載の大雑把なHTMLで充分。悩むだけ無駄。
>>298 見出しがないと本文が成立しないのは無作法。HTML以前の問題。
<h1>うんことは</h1> <p>くさいものである。</p> じゃなくて <h1>うんことは</h1> <p>うんことは、くさいものである。</p> にしろってことね
たとえばニュース記事を集めたページを作るとき、 <h1>海外ニュース</h1> <div class="news"> <h2>アメリカが北朝鮮に宣戦布告</h2> <h3>2003年3月1日</h3> <p>アメリカのブッシュ大統領は〜</p> </div> <div class="news"> <h2>北朝鮮が無条件降伏</h2> <h3>2003年3月3日</h3> <p>北朝鮮の金正日総書記は〜</p> </div> などとしているのだが、 日付がh3というのはおかしいかなあ。 見出しじゃないですよね、これ・・・
>>303 「北朝鮮が無条件降伏」という見出しの記事が、
2003年3月3日以外にあり、同じ<h2>の下に存在するなら
2003年3月3日というのが見出しであるといえるけど、
そうならないなら、見出しではないな。
305 :
304 :03/03/01 01:41 ID:???
<del>2003年3月3日以外にあり、同じ<h2>の下に存在するなら </del> <ins>2003年3月3日以外にあり、同じ<h2>の下に存在することがあるなら </ins>
<dl> <dt>2003年4月1日</dt> <dd><h2>フセイン大統領がチンパンジーを飼う</h2> <p>イラクのフセイン大統領が、ブッシュという名前の〜</p> </dd> </dl> これはどう?同じ日に大きなニュースが複数あった時にも対応できるし
2003年3月3日以外にあり、同じ<h2>の下に存在する<del>なら </del><ins>ことがあるなら </ins>
次の例ならいいんじゃないか <h2>2003年4月1日</h2> <h3>北朝鮮が日本に核ミサイルを発射</h3> <p>アメリカ主導の経済制裁が発動して〜</p> <h3>2ch閉鎖</h3> <p>東京壊滅を受けて〜</p>
ニュースサイトの場合、日付を基準にするか、トピックの見出しを基準にするかでhnの上に来るものが変わるしな。
>>306 dd の中は dd の中で世界が完結しているべきと思う
つまり dd の中の見出しはもしあるにしても本文と切り離すべきじゃないかと
日付1 見出し1 内容1 見出し2 内容2 日付2 略...... これを如何にマークアップするか、ということだな。 基本的に同じ日に複数のニュースがあることもある。1日1ニュースという 前提ならまた違ってくるのだろうが。
まあ、やりたいようにやれってかんじだな。 ニューストピックのみ h* の方が解析はしやすいけど。 切り出すとしたら、トピック単位に分けてから日付けを見るだろうし。
313 :
303 :03/03/01 02:58 ID:???
>>304-312 うん、やっぱり自分の思っていた通りだと
確認できました。
レスポンス、非常に感謝しております。
え?あれでもいいの?
316 :
Name_Not_Found :03/03/03 13:46 ID:5aUqD33i
>>317 <cite><a href="...">ほげほげ</a></cite>
引用先はこのサイトです このサイトから引用しました どっちでもいいんじゃないの
<cite href="...">ほげほげ</cite> ってできればすっきりするんだけどなぁ
引用元、で取り出す場合は <cite>...</cite> の中を取り出すから関係ある要素は中にいれたほうが。
<h1>仏教</h1> <h2>四苦八苦</h2> <p><dfn>死苦</dfn>とは、人生の四種の苦痛。生・老・病・死の総称です。生・老・病・死の意味は以下の通り。</p> <dl> <dt>生</dt> <dd>息をしている状態</dd> <dt>老</dt> <dd>歳を取った状態</dd> <dt>病</dt> <dd>病にあった状態</dd> <dt>死</dt> <dd>息をしない状態</dd> </dl> か、
<h1>仏教</h1> <h2>四苦八苦</h2> <p><dfn>死苦</dfn>とは、人生の四種の苦痛。生・老・病・死の総称です。生・老・病・死の意味は以下の通り。</p> <ul> <li> <dl> <dt>生</dt> <dd>息をしている状態</dd> </dl> </li> <li> <dl> <dt>老</dt> <dd>歳を取った状態</dd> </dl> </li> <li> <dl> <dt>病</dt> <dd>病にあった状態</dd> </dl> </li> <li> <dl> <dt>死</dt> <dd>息をしない状態</dd> </dl> </li> </ul> のどちらがいいでしょうか。
あと、下の方がいいのなら、ulではなく、olのほうがいいでしょうか。
何の躊躇もなく上 下にする意味は全くない
dt と dd が 1vs1 のペアだっていいきれれば こんな疑問わかないのにね。dd 複数あるメリットわからんわ。 候補が複数ならdd中にulいれりゃいいんだし。
よくわからんが、生・老・病・死の順番にも仏教的に深い意味があって
>>324 みたいな発想が出てくるとか?
だとするなら、
>>325 の疑問は ul ではなく ol の方が良いということになるんだろうけど、
自分なら、普通に
>>323 を採用します。
順番関係無いリストと順番関係あるリスト区別するメリットってどんなのだろ。 関係*無い*リストだと項目がソート出来るとかそれぐらいしか思いつかないなぁ。 メニュー項目なんかは ul で作ってる人多いけどさ、あれの順番変ったらまずいよね。 考えて順番決めてるでしょ?
言われてみれば
みんなほんとリスト好きだよなあ
ol って HTML でしかレンダリング内容決めれなかった時代の名残なんじゃないかなと。
ol 以外は順番が保証出来ない、ってなったら ul だの dl だの使ってるとこかなり書き直しになるな。
>>329 「メニュー項目」ってただ並べてあるだけじゃないの?
それが「目次」のつもりだったら確かにちょっと困るけど。
リストなんて突き詰めれば序列リストだらけになるぞ。
例えば料理の場合の材料を箇条書きにしたものはulで、 料理の手順の箇条書きはolってな風にすみわけはできてるわな。 ただ、<listgroup ordered="yes">なんて風に統合しちゃっても よかったかもしれない(非常に今更、非建設だが)。
>>336 明らかに型が違うものを属性で振り分けてどうするよ。
#まあ、明らかに違うと言うことが分からない、というのが争点だったりするが。
<h1>今日の予定</h1> <ol> <li>なんたらー</li> </ol> 見たいな場合でliが1つだけだと、2個目の予定ができるまでolで正しいのか、 実はulでもよかったのか確信が持てない場合があるな。
>>338 2個目の予定ができてもolで正しいのかulでよかったのかを悩む罠
>>337 明らかに違うってほどでもないんだよね。
<ul>
<li ex:no="2">...</li>
<li ex:no="1">...</li>
<li ex:no="3">...</li>
</ul>
の ex:no についてソートしてあるのが ol みたいな感じだし。
とりあえず、順序無しじゃないとマズーな例あるかな。
集合といった漠然としたものをHTMLで扱う必要があるのか?ってのもあるな。
>>334 メニュー項目の並び順には気を遣う人もいるよ。
一番見せたいものを上に持ってくる、とか。
話の腰をおってすみません。 ええと、色々HTMLについて勉強したいのですが どこから聞いていいのか解らないほどの初心者です。 本屋で本を買って勉強しようかと思ったのですが、怪しい本が沢山あるとの ことで、また本もそれぞれ安くないのでどうしようか迷っています。 すれ違いかもしれないのですが、strictスレ推奨HTML学習本などありましたら 教えていただけないでしょうか。 #ちなみに、HTML以外にXHTMLとCSS、javascriptにも興味があります。
>>341 考えたんだが、見て欲しいコンテンツへのリンクを上にもってくるのと、
順序が意味をなすというのとは違うような・・・
別に2番目のや3番目のコンテンツから見ても問題はないわけだし。
そういうの強制されるのもなんかイヤンだしね。
346 :
342 :03/03/04 00:48 ID:???
>>343 ありがとうございます。よんでみます。
>>345 知人に薦められて「スタイルシートWebデザイン-CSS2完全解説-」は借りて
みたのですが、サパーリだったので、こちらで質問させていただいたのですが、
ごく簡単なHTMLの説明をよんで、とりあえずこちらの方の本は読んで解りそうなので
ユニバーサルHTML/XHTMLを読んでみます。
ありがとうございました。
>>344 ol だって別に順番強制しているわけでも無い気もする。
先にでた例だと、
料理の手順なんかは順番強制だけど、ランキングなんかは強制じゃないし。
下手に例を出すと、こんどはその例に拘ることになっちゃうな…
>>347 順番に意味がある、ってことだろ?
だったら、「運営者が見てもらいたいと思ってる順番」ってのを明示しなきゃならんのではないの?
>明示しなきゃならん may とか can ではあっても must じゃないと思う。 ol は順序があるということを明示できるというだけであって 順序のあるものは全て ol でなければならないということではないだろう。
>>349 > 順序のあるものは全て ol でなければならないということではないだろう。
反対だよ。順序ないものをolにしちゃまずいんじゃないか、と。
禅問答か?
順序あり ───→ OL
──┐
└→
順序なし ───→ UL
ということか?
ならば、
>>349 と
>>350 は同じことを言っていると思われ。
>>351 違いがわからんのか?
「順序のあるもの」を「ul」にすることは出来るが、
「順序のないもの」を「ol」にすることは出来ない、
と言ったんだけど。
>>349 だと順序のないものがolにできてしまう。
ああ、補足ね。
>>
>>349 が言ってることは、あってるんだけど、
>>348 に対する指摘としては不適切じゃないか、って意味なんだよ。
俺が348で言ったのは、「ol使うなら、その理由が明確であるべきでは?」というもの。
「順序つけてあるけど、これ、なんの順番なの?」じゃマズくない?って言いたいわけで。
>>355 それは違うだろ。
「順序あるもの」を「ul」にしてもいいんじゃないか、って言ってるだけで、その逆については言及していない。
なんだかややこしくなってて、ケチつけてる人は何が不満なの?
俺は、例えばp要素は「段落はp要素で明示しなければならない」のと同じように 「リストは順番があればol、無ければulで『なければならない』」とおもう。 そもそも要素名の由来が「ordered」と「unordered」だし。 HTMLには「順番が無い『かもしれない』リスト」とか「順番が『あってもいい』リスト」 なんて概念は存在しない訳で、どうしても「順番にかんしてあやふやなリスト」 が本文に出現するならHTMLの限界としてあきらめるかどっちかを使うか、 DTDの書き換えやXMLで拡張するか、だと思う。
363 :
362 :03/03/04 21:14 ID:???
strictとか以前に日本語がバグってるな。特に >が本文に出現するならHTMLの限界としてあきらめる"か"どっちかを使うか、 は >が本文に出現するならHTMLの限界としてあきらめる"て"どっちかを使うか、 だな。 スレ汚しスマソ
さとみかんとかのアンテナって ol 使うべきなのかな。
更新日時順に意味のある順序で並べられているリストならolの方が 好ましいのではなかうか。 ただ、ulとしてもHTML文書としての価値はなんら減じないので あまり拘る場所もないとはおもうが。
>>362 お前さあ、略語はとにかく abbr 要素で明示*しなければならない*とか
関連文書は全部 link 要素で明示*しなければならない*とか思ってんの?
明示する*べき*だ、ならまだわからんでもないが。
俺はそのへん主導権握ってるのは仕様ではなく著者だと思うよ。
リストにしても、実際の順序がどうであるか、ではなく
著者が順序についてどういう情報を与えたいか、だと思う。
順番があれば ol、なければ ul、っていうより
順番があると明示したければ ol、ないと明示したければ ul、な感じで。
>>366 確かに。そこに意味があるかどうかを決めるのは著者だもんな。
お前さあお前さあお前さあお前さあお前さあ
>>366 対応したUAにHTML文書としてデータを渡すなら、仕様で定められた
マークアップがされていなければ不完全なHTML文書といわざるをえないだろう。
閲覧者側の処理がはっきりと限定されているなら(もしくは処理されなくても
構わないなら)限定的なマークアップする(すなわち、処理「されたい」所だけ
明示的にマークアップする)のでもいいだろうが、WWW上で公開され、その後
閲覧者や、処理方法を著者側が限定できないHTML文書であれば仕様に定め
られた要素に関しては全てマークアップ「されていなければならない」と考える。
>>367 明らかに、客観的に「見出し」であるにも関わらず、著者が「見出しとして処理
されなくてもいい」と考えて「h1-6でマークアップしない」と言う自由はHTMLには無い。
しかし、その一方でem、strongなどの要素に関しては著者が強調「したい」
要素を表すもので、これに関しては「著者が強調されなくてもいい」と思えば
マークアップしなくてもいいし、というか寧ろしないほうがいい。
で、おれはol、ulというのは前者(h1-6の例えの方)と同じく
「著者の自由な裁量で勝手にマークアップしたり/しなかったり」と言うことは
できない、と思うがどうか。
でも境界線をどこで引くかは結構微妙だぞ>ol, ul
372 :
370 :03/03/04 22:42 ID:???
>>371 うん。そう思う。なので、どうしてもあやふやな物を記述する場合、
妥協(?)して「どっちかといえば…」とどっちかでのが一般的だと思う。
が、「解らなければulでいい」とか、本来順番があるはずのリストを
「著者は順番を気にしないからul」ってことは無いはず、って事。
>362 うえの例が今回の話題の発端になっているわけだが、 「俺が見て欲しいと思ってる順番」なんてのは「順序があるリスト」とは言えないんじゃないかな。 「どっちで書くべきか」ってのも重要かも知れんが、それ以前に「それは本当に順序なのか?」という問題があるのでは。
374 :
370 :03/03/04 23:08 ID:???
ある程度ケースバイケースにならざる得ないが、俺が言いたいのは
>「俺が見て欲しいと思ってる順番」なんてのは「順序があるリスト」とは言えないんじゃないかな。
「順序があるリスト」と言えないならulでマークアップ、いえるならolでマークアップって事。
別にどういうリストは順番があるといえる、ないと言える、という判断基準は
おれは述べてなくて、もっと端的に言えば、
>>349 の主張は違うんじゃないかって事。
>>374 言いたいことはわかるが、
> 「順序があるリスト」と言えないならulでマークアップ、いえるならolでマークアップって事。
「順序がある」「順序はない」を判断するのは著者、ということになっちまわねえか?
例えば、「好きな食べ物リスト」。
箇条書きならulだが、それでも一番好きなものとか2番目に好きなものとかがあるわけで、
「じゃあ、そのとおりに並べてolにしやがれ」ってのも微妙な部分だし。
結果的に「順序」を発生させるのは制作してる人間の判断に依るところもある、ってのもあり得るんじゃない?
376 :
375 :03/03/04 23:31 ID:???
あー、反論じゃなくて、 「大元の話題は」って意味だからね。
>>375 著者を「A:文章を作る人」「B:HTMLをマークアップする人」に別けた場合、
Aは自分が作る文章ないに出現するリストを順番ありとしても、なしとしても
作る事ができる。
例えば「セ・リーグ6球団」を単に列挙したリストなら「順番なしリスト」だが、
続いて「順序は昨年の成績に寄る」って一言書けばリストとは関係ないセンテンス
によって「順番なしリスト」はたちまち「順番ありリスト」に変化する。
その意味においてAである著者はolとulの決定権を握っている。
しかし、一度文章が完成し、Bパートにおいて単にマークアップするのであれば、
Bであるところの著者はAパートで作成した本文に忠実であるべきであり、
「マークアップの段階でBの著者に自由裁量権は存在しない」とおもっている。
したがって、
>>375 の言う著者がAの意味であるならば全く反論はない。
378 :
377 :03/03/04 23:41 ID:???
>>377 そしてCパートでCSSによるレンダリング指定。
>>377 そんなんBがAに聞けば済むことじゃん。
テキストありきのマークアップでしょ。
381 :
377 :03/03/05 00:56 ID:???
>>380 たのむよう…、レス付ける時は読んでからにしてくれよう。
いや、だからさ、ol だけでよかったんじゃないのかって話をしたかったんだが。 文章をモデル化したとき、順序付きリストと順序無しリストを区別する必然性って どれぐらいあるのかな?と。 現行の規格にolとulがある以上、適当なところで線引して使ってかなきゃいけないけど。 所詮適当な線引しかできない曖昧なモデルならもっと抽象化して 直接的な意味は上に被せる別のセットに委譲してもいいんじゃなかろかと。
383 :
377 :03/03/05 01:25 ID:???
>>382 現行HTMLが実際ol、ulに分かれちゃってる以上、それに従うしかない。
とは思うが、実際の所「特に順序がある場合だけそれを明示」の方が
現実に即してる(書き手が楽。迷わない)とは思う。
ちなみに一本化するならolもulも名前が不適切なんで
>>336 の案に一票ってことで。
私もw3cに提言するなら
>>336 だな。
ただ、ordered="true"ね。
(箇条書きリスト) ⊃ (通し番号付きリスト) ⊃ (順序に意味のある序列リスト) UL UL OL ↓ ↓ list-style-typeで番号付け デフォルトで番号付き ってことでしょ?
>>385 序列じゃないのに通し番号がある、って部分がややこしくさせてるんだよな。
通し番号って、不要と言えば不要だし、必要と言えば必要だよな。
>>385 違う。
HTMLにはない順番あり・なしを包括するリスト要素={ol,ul}
であり、ulとolは別物。olでulの、ulでolの代用はできない。
388 :
387 :03/03/05 02:10 ID:???
ごめん、わかりにくかった。 >olでulの、ulでolの代用はできない。 要するに ul と olは同列の要素であって ul ⊃ ol と言うような 包括関係は関係は成立しないってこと。 あと、番号がついてるとか、ついてないとか言うのはHTMLのデフォルトレンダリングの 話で要素の定義(明示する意味)とは関係しない。 (がXSLTのSはStyleのSだったりするからHTMLは固定スタイルを持ってると 判断すべきだんんだよなぁ…ややこしいなぁ…)
>>388 > あと、番号がついてるとか、ついてないとか言うのはHTMLのデフォルトレンダリングの
> 話で要素の定義(明示する意味)とは関係しない。
だから、olにせずにulにしてるんじゃないの?
>>389 ol は ordered list の略であり順番ありリスト。
一方 ulは unordered list の略であり、順番なしリスト。
従って順番の有無=条件Aに関してAとnot(A)という対立する関係にある。
だから not(A) ⊃ A は成立しませんよ、と言う事。
精緻な刑法解釈学を彷彿とさせる議論が続いているな。
olとulは特別関係であると考えることも十分に可能なはずだ。 必ずしも択一関係ではないのではないか。 より一般的なリストがulであり、ulの特別類型として、順序という 意味を付したものがolである。 ulとolのどちらを使うかを考えるにあたっては、まずulでリストを 作ってみる。そしてそのリスト内で指定した<li></li>をぐちゃぐちゃに 入れ換えてみて、依然として文意が通じている(通じているかどうかは 前後の文脈も含めて判断する。例えばリストの前に「セリーグ一覧です」と 書いてあるのと「僕の好きなセリーグを順に並べてみました」と書いてある のでは、後者の場合ぐちゃぐちゃにすると、文意は破綻する)。 したがって、例えば、料理のレシピを提示する場合は、ulで作ってみて ぐちゃぐちゃにすると、文意は成り立たないから、olを使うべきだという ことになる。 ここで問題となるのが、ulで作ってみてぐちゃぐちゃにしても意味が 通じている場合に、あえて番号を付けたいとき。そのような場合においては、 番号は単なるレイアウトであるから、ulを使った上でlist-style-typeを 適用してしかるべきであると考える。
ulの場合は、<li>で示された各要素をレンダリングする順番は 保証しないっていうブラウザを想定して、そんなブラウザで 標示されても構わないならul、NGならolってのはどうよ?
>>392 だいたい同意だが、
> ここで問題となるのが、ulで作ってみてぐちゃぐちゃにしても意味が
> 通じている場合に、あえて番号を付けたいとき。
これってどんな場合だろう。
思いつかないので、具体的な例を希望。
>>395 それはないだろ。
age sage の意味がなくなる。
とにかく、敢て ul を採用しなくちゃいけないケースが無いなら、
ol だの ul だの区別しない list 要素を作った方がいいよね。
オブジェクト指向風に要素の拡張出来ればいいんだけどな。
ol extends list とか ol implements list みたいな。
menu extends ol とか persons extends list とか…
dtd いじって既存のを修正するよかこっちのがいいなあ。
>>394 どっかのスレで出てたけど、クイズの問題の選択肢
Q. W3Cが決めていないフォーマットは?
1.HTML
2.CSS
3.javascript
4.XML
これなんかは番号がついてはいる物の順番が出鱈目に成ってもokなのでは?
(ただし、正解を番号で言う事はできなくなるが、もともとCSSで表示される
ナンバーはユーザーCSSとの兼ね合いでolでもulでも信用できないし)
逆にクラス名簿なんかは五十音順であっても、出席番号いらなけれ
olでマークアップした上でCSSでナンバー消して
・青木
・秋山
・木村
・久保田
なんてものありだな。
久保田・・・ 最近呑んでないなぁ(つД`)
399 :
397 :03/03/05 23:19 ID:???
つーか、五十音順の名簿のナンバーを消す、なんてややこしい例じゃなくて、 日記の過去ログリストなんかは、 1.1月 2.2月 3.3月 ってのが煩わしいので、確実に順番はある(ol)がCSSでナンバリング消してる人が多そう。 っていうか自分のsiteでやってますた。
まあ、ul より ol 使った方がよさげかもしれない場合も 多いんじゃないかってことですね。 ul 使おうが ol 使おうが UA にもユーザにも全然違いが出ないだろうけど。
いっそ ol は「序列リスト」でなく「番号つきリスト」だったら 今より断然使い勝手が良かったような気がする。
>>402 OrderedList coludn't be NumberedList.
>>403 だから、ol なんかじゃなく nl だったらよかったってことなんじゃないの?
>>404 それはXHTML2.0でnavigation listになってますので別の名前を。
じゃあ、nul… ぬるぽとか言いだす香具師はこのスレには居ないよな?
( ・∀・) | | ガッ
と ) | |
Y /ノ 人
/ ) < >__Λ∩
_/し' //. V`Д´)/
(_フ彡 / ←
>>407
<meta name="generator" content="○○○" /> これは何を表すのですか? その文章を書いたアプリとかを書くのか、表示に用いている cgi を書いた方がよいのか・・・ ジェネレータってことだから、やはり後者かな。
>>409 後者じゃない?やっぱ。
エディタとか入っててもね。
notepad.exe とか入れてるやつはちょっとどうかしてると思う。
今日はごっついテーブルレイアウトが目の前でリアルタイムに構築されてくのを
ひたすら傍観してました…
css はおろか align 属性すら使わない人がいまだいたとは予想だにしてなかった。
>>409 meta の name なんて別に決まりは無いんだけど……。
取り敢えず、前者の例は見たことがある(Wordとかで書くと入るんだっけ?)。
後者の例は見たことないなぁ。
ホームページビルダー(アプリ)やtDiary(CGI)が入れているね。
>>410 align属性は非推奨だからいいんじゃない(藁
>>407 またえらく古いネタを。
それにしてもこの論議は長かった。
>>410 >css はおろか align 属性すら使わない人がいまだいたとは予想だにしてなかった。
CSSを指定していない"strict"文書?
>>411 > meta の name なんて別に決まりは無いんだけど……。
そうだっけ?たしか決まり有ったと思うが。
みんなが適当に入力してるなんて琴はないかと。
>>414 HTML 4.01 Specification より
This specification does not define a set of legal meta data properties. The meaning
of a property and the set of legal values for that property should be defined in a
reference lexicon called a profile. For example, a profile designed to help search
engines index documents might define properties such as "author", "copyright",
"keywords", etc.
質問。
<a href="mailto:
[email protected] ">ひろゆき</a>
みたいに、href属性の値の中の、スキーム名とかコロンを文字参照にすると
仕様上問題はありますか?
>>417 古いブラウザで解釈できないかもしれないという点を除けば仕様上は問題ないです。
419 :
417 :03/03/07 00:40 ID:???
>>418 ありがとうございました。
Another HTML-lintでエラーが出るんですが、これって多分バグですよね。
今日は眠いので明日にでもk16さんにメール送ってみます。
例えばircでのログを転載する際の疑問なんですが、 引用と言えない気もしないでもないんですよ。 で、引用とするならばどうやってマークアップします? 数行に渡る内容ならblockquoteにpreでいいかなと思ってますが。
>>420 転載なら当然引用だろ。
そして、blockquateにpreって
<blockquate><pre>
転載内容
</pre></blockquate>
ってことか?
私なら
blockquate.irc_log {
white-space:pre;
}
<blockquate class="irc_log">
転載内容
</blockquate>
あと、もっと分かりやすく書いてください。
>転載なら当然引用だろ。 ……。
>>421 余談だが、blockqu"a"te という癖は早めに直しておいた方が良いと思われ。
424 :
421 :03/03/07 01:57 ID:???
>>423 Dr.Calvin.F.Quateがきになって……
うそです。
∧||∧
( ⌒ ヽ
∪ ノ
∪∪
>>420 引用か、転載かの判断は法的な問題になるのですれ違いって事で。
IRCの内容転載なんかまさにケースバイケースの世界で具体的に全文読まないと
判断できないし。
ちなみに引用の場合のマークアップは当然blockquote要素の出番ではあるが、
それって本当にpre要素か? 整形済みデータとして改行位置変わったりすると
不都合あるのか?
マニアックに言えば発言者をdt、発言内容をddとするのが(dl要素の例にも
出てる訳だし)だとうであろうが、ぶっちゃけ面倒くさいのでpとかdivで
発言単位にマークアップするのが良かろうかと思われ。
引用は著作権の有無にかかわらず常に認められる(言論の自由)が、 転載は著作権が絡んでくるので、どちらかというと「複写」の概念に近いのではないか? とすれば、前者は当然BLOCKQUOTEとなるが、後者はBLOCKQUOTEではない。 ベタテキストをPREとすること自体は(横着ではあるが)問題ないと思う。
>ベタテキストをPREとすること自体は(横着ではあるが)問題ないと思う。 ベタテキストのなんか文章があったとして、 明らかに見出しの部分とか、明らかに段落の部分とかあるんだけど 横着してh1-6要素やp要素のマークアップしなくていいの? 少なくともstrictスレ的にはNGだろう。
>>427 IRCのログに見出し部分があったとしても、それは「本文」の見出しとは違う。
転載という以上は同一性を保持しなければならず、元がベタテキストであることを
HTML的に明示するには、PREを使うのがいいと思ったのだが、どうだろうか?
>>421 blockquote内にじかにテキストって置けたっけ?
>>428 >IRCのログに見出し部分があったとしても、それは「本文」の見出しとは違う。
IRCのログはそもそも整形済みテキストとも違うからすくなくともpreではないだろう。
なお、仮に既存のどの要素でも表現できないなら <div class="irclog"> かな?
>>429 strictではできない。
>>429 置けない。ま、そういう指摘は揚げ足取りにしかならないかと・・・(藁
>>430 あ、strict じゃない場合は、置けるんだ。知らなかった・・・
>>431 要素名のtypoは揚げ足取りかもしらんが、strictスレで要素の内容まちがえちゃったら
ダメだろう。
皆ならどっち使う? ──────────────────── <address> hogehoge<br /> hugehuge </address> ──────────────────── <ul> <li><address>hogehoge</address></li> <li><address>hugehuge</address></li> </ul> ────────────────────
部分的に取り出されてもなぁ。
どちらでもなく address {white-space: pre;} とか address span {display: block;} ってのは?
>>2 の過去ログ XHTML1.0 くらいを"address"で検索しながら読むと幸せになれるかも。
440 :
Name_Not_Found :03/03/07 13:58 ID:jjGSTB2G
addressはHTMLで全体構造にかかわるものとして定義されているから 後者のように階層を深めるのでなく前者のように浅くするのがいい。 > address {white-space: pre;} とか address span {display: block;} ってのは? accessibilityの面から考えてこの場合brは問題なく、むしろ、 CSSの指定のみでは、accessibilityの面から考えて問題があり、 また、spanの利用では、spanの意味することが汎用的過ぎるから、 複数の連絡先の区切りがわかりにくくなるのでよろしくないかと。
廃止予定の物理要素を使おうというのは このスレ的にイケてないと思うわけだが。
曖昧なaddress要素は使えない 曖昧なmeta要素は使えない 曖昧なlink要素は使えない セマンティックにしたいなら何でこれらをもっと明確に定義しないんだろ
443 :
440 :03/03/07 14:43 ID:???
>>441 それが気になるのなら、中黒(・)でも使って列挙するのがいいのでは。
>>442 まあ、昔に定義された現行の規格の定義に文句たれてもしかたないし。
XHTML2.0以降にたいして文句たれよう。
HTMLを見限って独自の合理的なマークアップを広めるのも手かもね。
css 使えばIEとかで見えるし、HTMLであることを利用したUAなんて殆どないだろし。
>832 それいい!!(;´Д`)ハァハァ そこでアニャ-ルを是非是非是非!!
すいません、誤爆しました。
>addressはHTMLで全体構造にかかわるものとして定義されているから どこで定義されてる?
「address=著者についての情報」では
>>442 もう少し詳しく教えて貰えません?
“使えない”というのは“利用価値がないから、書かない方が良い”ってことですか?
“曖昧なもの”と“曖昧でないもの”の違いも分からないんですけど。
meta や link って、どこまで書いておけば良いのか・・・
>>452 きっちり決まってないから、利用する方も安心して利用出来無いんだよね。
結局書いてないことを前提にして、
かつ書いてあることもあんまりあてにならないってスタンスでやるはめになる。
著者情報はRDFデータソースの形で提供するのが今後は間違いがなくて良いと思う。
dublin's coreの語彙を使うやつですか? 詳細は神崎さんとこ見てると載ってると思う。
>>435 亀レスだが、
単一の著者ののサイトのアドレスとメールアドレスを併記するなら
<address>サイトのアドレス<br>メールアドレス</address>
著者Aと著者Bのメールアドレスの列挙なら
<address>著者Aのメールアドレス</address>
<address>著者Bのメールアドレス</address>
と俺なら書く。
あと
>>435 の書き方はアドレスを外して考えた時、
上の方は単一ブロックの内容、下はリストの内容になっていて、
あまり例えが良くないように感じた。
単一ブロックの内容の対になるなら複数ブロックに分割された内容として
表現されるべきではなかろうか。
458 :
457 :03/03/07 20:03 ID:???
>>440 複数の連絡先がかかれる場合、例えばDOM的にその内容を取り出すならば
document.getElementsByTagName("ADDRESS")[n]
となるわけなので、一つの連絡先は、一つaddress要素で、という考え方の
ほうがべんりだなぁ、とおもって俺は
>>457 の様にしている訳ですが、
どうでしょう?
一人の著者に関する情報でも、複数のサイトアドレス、メールアドレスや 場合によっては、現住所や電話番号などをリスト風に列挙したい場合もあるのに address要素がインライン要素しか内包できないってのがねぇ。。。 <BR>しかありませんよというのが、どうにも不細工な感じ。。。
過去スレでもさんざ既出だね。
どうせ address を利用するUAなんてないんだから
使わないってのも一興かと。
著者情報ってのはメタな物だと思ってるので
>>454 なやり方でやってます。
>どうせ address を利用するUAなんてないんだから >使わないってのも一興かと。 「今」対応UAがないからといって、今書いた文章が将来対応UAで読まれないとも 限らない(と言うか寧ろそっちのほうを考えるべき)し、 MozillaのXULなどユーザーサイドでただ今すでに利用中かもしれん。 少なくとも現状の実装状態で物を語るのはstrictスレ的ではない。
HTMLは意味に応じて<em>整形</em>するのが主用途なのでそれでいいのです。 データ抽出なんてのはただの副産物。 …だったんだと思うよ、もともと。もちろん憶測だが。
>>461 <LINK rel=…> も、最初は「Lynx以外でこんなの意味あるのか?」とか思っていたが
IE以外では具体的なUIとして実装が進んでいるようだし、
ADDRESS要素についても、あるべき姿というのを実際に見てみたい気がする。
XHTML 2.0でaddressは見直しがあるとかいう噂があったが。 どうもaddressは好きになれん。
addressのあるべき姿って…。 他の要素のあるべき姿は今のメジャーな実装でいいのだろうか。 てか、やっぱブラウザ上の目に見えるUIとして存在することがあるべき姿?
メールアドレス収集ロボットは「実装」しているかも。 どうもaddressは好きになれん。
いきなりですが、meta name="generator" を書いておく意味ってあると思いますか?
>>461 見限る必要もあると思いますよ。
識別情報としてならrdfで提供するタイプが増えてきてますし
そっちにシフトしていくと思う。
address はいっそ strong とかみたいなインライン要素になってほしいなぁ。
var だの dfn だのと同じような位置付けね。
>>467 好きにしろとかしか言えない。
google は description とか keyword(s?) を読んでるみたいだったけど。
generator 利用している例ってのはまだ見たことないな。
>>463 どうなんだろう。Operaの見出しジャンプみたいに、address内部にある
アンカーは著者向け連絡先リンクと見なされてコンテキストメニューから
「著者へ連絡」を選ぶと対応した動作が期待できるとか。
激しくlink要素で足りてる予感w
ちなみに俺はそれでもaddress書くけどな。
なぜかっつーと、時々わざわざプリンターで紙に出して読んだり、保存したり
する人がいて(特に年配者に多い)、その場合、殆どのhead要素内の情報は
(つまりlink要素による署名は)失われるから。
やっぱaddress自動収集かね。 それも link の方の方が確実か… 結局"文章内容としての筆者情報"用要素ってことなんだろうな。
>>471 うん
マナーとしても文書内に署名は必要
>>473 でも、一般的なUAがlink要素に対応したらいらなくなる、過渡期のマナーっぽ。
UA が link の内容を解釈して 文章の最後に著者情報を整形して表示したり 印刷したらページ毎の最後に小さく表示したりとかするようになったら マナー違反にもならないっしょ。実際書いてるわけだし。
>>472 微妙に誤訳チック。
〜 may be used to … は
「〜は…するのに使えます」ぐらいが自然な感じの訳だと思う。
その文章は address 要素の用途について触れているだけ。
>著者の裁量で使うの辞めてもOK?
こんなことについては一切触れてない。
ValidなCGIやPHPについてのスレって…WEBプログ板ですかね。 それともこっち?つーか需要ってなさそうだな…閑古鳥スレになりそう。
478 :
Name_Not_Found :03/03/07 23:51 ID:hjg1xR0t
>>477 個人的には、そういうスレ、あって欲しい。流行るかどうかは別の話なんですけど。
フルスクラッチで書くんだったら valid な html 吐かせるのはたいした問題じゃ無いと思うが…
(このスレ的な意味で) strict にできるかどうかが問題。
せいぜい典型的なBBSの構成要素はどういう要素を使うべきか?ぐらいだろ。 出力は自分で制御できるんだし。 どうでもいいが 発言者-メッセージのペアを dl にするのはどうかと思う。 おまえdl使ってみたいだけちゃうんかと。
確かに、tableを否定された結果、dlのオンパレードに なる傾向というのは存在するな。 お前そこはtableでいいだろっていうところまでdlを 使っている奴もいる。
写真(画像)とそのキャプションで しかたなくdl使いまくり
でもさ、tebleって strict に書くのめんどくない? その点、dl は楽だから・・・
面倒って理由で避けるのはどうかと思うなぁ。 css憶えるの面倒だからtable使いますってのと同じ匂いがする。
487 :
485 :03/03/08 00:53 ID:???
>>486 どっちでもよさげな場合に dl に流れるわけだよ
どう考えても table な場合は table 使うけど
DTとDDの対応関係は、そのままTHとTDの対応関係に変換可能なのだろうか?
doctype無し、table厨なHTML描いてて、心が痛んでいます(つД`) ローカル内で使用(CD-ROMに収録)といえども、オシゴトってば、ほんと辛いでつ(泪)
>>490 valid な html で書いてはいけない仕事?
仕事は仕事と割り切って頑張ってください。そんなのは適当にやっときゃ良いじゃん。駄目か?
愚痴は他所でやれって感じだ
スト陸太は愚痴りたいのさ。
特に価値のない文書に関しては、 valid な html とやらで mark-up したところで、 単なる自己満足でしかないというか。 読めれば、それで良し。
これをストリクタの憂鬱と呼ぶ。
496 :
UA :03/03/08 02:06 ID:???
text/htmlで送られてきたんです。 ところが文書がinvalidで苦労しました。 しかも価値が無かったらしくて、 ユーザさんは速攻で閉じてしまいました。 一生懸命レンダリングした私の立場は……
>>496 これから一生懸命レンダリングしますが、よろしいですか?
とか聞いたれや。
きちんと「No」を選んであげるから。
>>496 オイオイ、漏れに丸投げしといてよく言うぜ。
object要素の有効活用しているサイトが見当たらない。 画像はimg使った方がいいし。
>>496 俺なんて mime type 無視してまでレンダリングしてるのに
文句たれられるんだぜ。やってられんよ。ほんと。
>>500 どこかでソースファイルをobjectで読み込ませようとしてたサイトがあったけど
うちの IE は text/plain 用のプラグイン探しにいっちゃった気がする。
object使ったときの、画像と外枠との間の余白は一体どうすれば制御出来るのか・・・
W3C信者の方にすら見放されてますが、何か。
ハンドル変えたんですけど、 リアクション少ないんですよね(´・ω・`)
UAになりきって語るスレはここですか
>>505 きめら→かみの
でしたっけ?
ねこめし日記では取り上げられてましたよ。
きめら便利セットが、髪の便利セットになるとかならないとか。
おいらの名前はどうなるんだろ…
以前は Seamonkey って呼ばれてたんだけど 覚えている人いるのかなあ(汗)
a:hover.link? or a.link:hover?
>>512 Sorry....
.link=class
>511 スレ違い。CSSスレへどうぞ
ちょっと前にカスイケスレで振ってしまった話なんだけど メールフォーム等の整形は完全にCSSでやるべき? 例えばラベルとフォームの構成部品を改行させたい場合、 <form> <p> <label> お名前<br> <input type="text" ~> </label> </p> </form> として<br>を使うより<span>お名前</span>としてdisplay:blockのほうがいい? tableという方法もあると思うんだけどストリクター的にはどう思いますか?
別に br を使っちゃ“いけない”なんてことは無いと思うが……。 display: block でもいいけど、table はちょっと大仰に過ぎると思う。
個人的には UI 専用のセットがでてきて欲しいなぁ、ってとこなんですが、 form 廻りは br とか使わないで label - input の組みを ul で並べたり p で流したり dl で並べたりして適当に css で整形するといったかんじ。 css で出来る程度で無理矢理満足してる感もいなめない。
ところで input の後にあるチルダは何。
>>515 <form>
<dl>
<dt><label for="name">お名前</label></dt>
<dd><input type="text" id="name"></dd>
</dl>
</form>
とかじゃダメなのか?
>>519 間違っちゃいないとは思うけど、何でも dl って感じがして嫌なのかも。
521 :
515 :03/03/08 17:29 ID:???
みなさんレスありがとうございます。こういうフォームの集まりはリストとも言えるし
一つの表としても捉えることができますよね。
悩んでいるのはlabel要素によってラベルと部品は関連づけされているので
ソースをこれ以上大げさにしないほうがいいのかなとも思いまして。
自分は部品とラベルのセットをさらに<p>でくくってお茶を濁してますが
これであってるのかどうか・・・。
>>518 以下略って意味っす。半角にしたら変になってしまいました。
>>515 <form>
<p>
<label for="hogehoge"></label>
<input type="text" id="hogehoge" />
</p>
</form>
でいいと思うんだけど。仕様書でもそうしてるし。
構成をまとめるなら<feildset><legend></legend></feildset>を使う。
>>520 んー使うべきところなような気がしないでもないんだけど。
俺は大体dl使って書いてる。
横に並べたい時はfloatで。
場合によってはtable。
>>521 どうせならlabelにdisplay:block;でも良いかもね。
labelにinput含めなければいけないというわけじゃないし。
>>522 いや、それじゃ改行されないんじゃ?(w
>んー使うべきところなような気がしないでもないんだけど。 うん、そうなんだけど、ぱっと見ソースがdlだらけでこれでいいのかなぁって疑問がよぎる。 もっとも p ばっかりの時点で疑問いだいてないんだから杞憂だろうけど。
legendが適正かどうかはべつとして、 グループ単位で1行にしたければlegendでもdivでもつかってあとはCSS。
526 :
515 :03/03/08 19:07 ID:???
>>522 ありがとうございます。色々考えて一番シンプルな
>>522 の案でいくことにしました。
…と思ったらネスケ7.0でlabel要素にdisplay:blockが効かない…。
Winの、IE6.0、Opera6.05、Opera7.02は改行できたのに。
(´・ω・`)ま、いっか。
527 :
515 :03/03/08 19:11 ID:???
>>523 label要素にfor属性があるのを知りませんでした。
ずっとinputも含めなきゃなんないと思ってて。勉強になりました。
では名無しに戻ります。
strictな掲示板を作っているのですが、 本文の色を選択できるようにとの要望がありまして、 どのようにマークアップすべきか悩んでいます。 class="red" だと今一なので、良い方法がないものでしょうか。
>>528 class="user_color_red"
とかして、何とかごまかすしかないような気がします。
掲示板で選択する色の意味はまさに「色」なんだから、 class="red"でいいんじゃねーの?
>labelにinput含めなければいけないというわけじゃないし。 うん。でも(IE非対応の) <lavel> hoge <input /> </lavel> ができないのが悲しいね。 いちいちidつけて forで指定するのも面倒だし。
redとかやってると細かい色が増えてくると名前つけるのが面倒になるので user_style_1 nser_style_2 とかってやった方がイイカモ。
×nser ○user んざー… イッテクル
プルダウンで色を選択させるなら 「クラシック」「キュート」「ナチュラル」みたいにごまかしておいて、 将来も「赤」「緑」である保障をなくしてしまえ。 そうしたらclassもclassic / cute / natureみたいにできる。 別にy1,y2...でもいいんだけど、 「色」は全ての環境で表示されるわけではないから、 やめておきたい、俺は。
だな。一段かまして曖昧にしておくのが基本だね。
536 :
528 :03/03/08 21:22 ID:???
質問者じゃないけど掲示板の色について語ってくれた人ありがとう。 ちょうど同じ場面で悩んでた。
一度「赤」って言う意味をせっていしちゃったら、それは如何なるCSSを 使おうとも赤なんだろ? 違うCSSをつかったら、赤で書き込んだ情報が 緑になったりはしないんだろ? だったらstyle属性をつかってしまえ! style属性をHTMLに書き込むのは良くないって奴もいるが、「だったら、 掲示板の選択肢に「赤」とか「緑」とか色指定の内容を書くな」。 掲示板の書き込み色指定ができるって段階で既に既に非strict。 #「赤い字の所が本年度の情報です」って言うような文章がWAI的ではないってのと同じ。
何興奮してんの
本末転倒な話になってきたようだ。 何のためのStrictなんだか。逆に縛られている。
それもまたよし
>>540 >>538 は逆に言えば、色指定する掲示板はstrictに向いてないってってるんじゃ?
style属性つかえとか。
投稿者の気まぐれで色指定すれば、どんなクラス名・選択肢名にしても 意味のない見栄え指定目的のマークアップにだよね。 # 個人的には見栄え指定マークアップが意味を兼用してなきゃ # 別にいいだろうと思う。
>>500 objectを使ってdisplay:noneでカウンタスクリプト(count.php)を置いてます。
>>500 つうか、objectを有効に活用しないUAが96%のシェアだからじゃねー?
objectの法が好きだけどつかってない。面倒だから(藁 img altだけで表現できないことができる(HTMLが使える)から委員だけど。
いまんとこimg使っててもStrictつーかValidだしね
XHTML2.0で img 要素が逆転非推奨ってことになったらまた話は変わってくるのにな
img要素が空要素になった経緯について知っておられるかた または、参考になるページとかご存じないですか? imgがobjectのように内容を含むことができれば alt属性の有無でごちゃごちゃすることもなかったろうに。。。
>>549 非推奨も何も、XHTML 2.0 には
最初から img 要素はありませんが……。
逆転で非推奨(というか削除)になったのは acronym や br でしょ。
>>550 多分昔の SGML での一般的な慣習を踏襲したものだと思うけど。
ちなみに、何で SGML では img (相当の)要素を空要素として
記述することが多かったのか、ていうのは、当時の SGML ってのが
今に較べてかなりシステム依存性の高い言語だったってことに
起因してるんじゃないかな。
要するに、当時の SGML は WWW でグローバルに
情報共有したりするためのフォーマットじゃなく、
比較的ローカルな環境であらかじめ決まっている目的を
遂行するための手段だったんだよね。
つまり、もし img 要素を記述するとしたら、それは
「画像を添付する」という唯一の目的のための記述であって、
「画像を表示できない/しない場合は」なんて仮定には
全く意味がなかったんじゃないかな。
ソースを読む人のためのコメントとして「画像の説明」を
記した属性を書くことはあっただろうけど、
出力結果として表示されうる「内容」として「代替テキスト」を
記述するのは確かに無意味だし、むしろ紛らわしいかもね。
# しかも、SGML の省略/短縮関係の機構の多さに顕著なように、
# 当時はデータの量を減らすことも非常に重要だったわけだし、
# 代替テキストなんていらねー、って人の方が多かったのでは?
以上、かなり憶測まじりなので参考程度に留めるて下さい。
つーか想像の域を出ないかも(w 概ねあってるとは思うんだけど。
(って、最後に書かずに最初に書けよって感じですが)
ところで特定の要素が多くなるのって悪いことかな? そうすることがよりstrictであるなら仕方ないんじゃないの
557 :
550 :03/03/09 21:51 ID:???
>>553 >>555 早速の回答ありがとうございます。
Web KANZAKIのページは、以前も読んだことがあったのですが
経緯の部分について「結局」としか触れられていなかったので
少し気になっていたのです。
データ転送量については
<img>代替テキスト</img>
としても
<img alt="代替テキスト">
としても大した違いがないので、何か他に空要素にしなければならない
重大な理由でもあったのかなと思った次第です。
>>557 XHTML2でそうなりますよ。<TagName src="URI" type="ContentType">代替テキスト</TagName>
例1:<span src="picture.jpeg" type="image/jpeg">[出発ロビーでの集合写真]</span>
例2:
<script src="default.pl" type="text/x-perl"><!--既定スクリプト(Perlscript)
<script src="alternate.js" type="text/javascript" /><!--代替スクリプト(Javascript)-->
</script>
560 :
559 :03/03/09 22:57 ID:???
typoあり。適宜修正して。
>>558 「何か物体」を表す object だけじゃなく、「絵」を示す要素型として
img もあったっていいじゃないか、という話では。
XHTML 2.0 では img も object も a も廃止されかねない勢いだし。
現状の code/var/samp/kbd みたいなのは統合されちまえって感じだが。
>>559 微妙にズレてる…。
そういう意味では HTML 4.0 の時点で「そうなってる」わけだが…。
img を汎用化したのが object 、object を汎用化したのが
XHTML 2.0 の src で、代替テキストの属性→内容は object で既に
実現してるわけで、そもそも話はそこから始まったわけで、
あのうそのう…とにかくもちつけ(おれが)。レスはよく読もう。
562 :
559 :03/03/10 00:16 ID:???
> object を汎用化したのがXHTML 2.0 の src 違う。
563 :
550 :03/03/10 00:19 ID:???
>>559-561 XHTML2.0はなかなか面白いですね。
まだ草案の段階なので詳しく読んだ訳ではありませんが、
src属性やhref属性が随分と拡張されているのに驚きました。
全ての要素にid属性とhref属性が指定できるのであれば
わざわざa要素を残しておく意味はないと感じました。
しかし、外部スタイルシートの <link rel="stylesheet" href="..."> は
残っているようですね。なぜ、link要素でhref属性なのか
感覚的によくわからないところではあります。
>>562 XHTML2.0のobject要素がsrc属性でなくdata属性なのはなぜか?
宜しければお教え願います。
564 :
559 :03/03/10 00:25 ID:???
* data属性でなくsrc属性の拡張だから。 * achieve属性は拡張していないから。(もしそうならこれらの属性も拡張されるはず)
565 :
341 :03/03/10 00:29 ID:???
> 外部スタイルシートの <link rel="stylesheet" href="..."> は残っているようですね。 スタイルシート用途はxml-stylesheet処理命令に統一されるように思う。 link要素が残っているのはその他の用途のため。
567 :
559 :03/03/10 00:40 ID:???
>>556 いや、見間違い。やはり残っていました。
しかし人それぞれの Strict があるっていう状況は問題だな。 なんのための共通フォーマットなんだか。
使いやすい構造を作成できればそれでいいのです。
>>570 誰が使いやすいか?じゃないの?
html の場合書き手が書き易いかじゃなくコンサセンスの方が
優先されるべきじゃないのかな。
書き易い構造でコンサセンスを取れれば最適なんだろうけど。
コンサセンス(w
コミニュケーションをはかる だろう。 ●2点
いくらHTMLをvalidに書いても日本語がinvalidだとねえ…
意味が通じるかどうかは結局のところ使用者の脳内補完能力に依存する、と。
日本語が strict じゃ無い人はこのスレきちゃだめですか。そうですか。
のじたんの日本語はstrictですか?
>>578 strict というより restrict。
旧 漢 字 ・ 旧 仮 名 遣 い は 糞
>>580 激しく同意。ウザイ以外の何者でもない。
HTMLやCSSばかりValidを追求して、肝心の日本語がInvalidじゃあ
タチの悪いジョークにしか見えないね。
みんな、自分のサイトは有料で広告無しスペース、審査とおって広告無し、自宅鯖で やってるの?
本名に旧漢字の使われている私は逝ってよしですか?
>>581 >Invalidじゃあ
HTMLに例えるなら単に旧versionのDTDつかってるだけだろ?
のじたんに言わせれば現在の日本語はHTML3.0みたいに、破棄されて当然って
物なので、私は(例え国家がDTDの破棄を宣言しても)HTML 2を使いつづけます
っていってるようなものでは?
>>583 アンダースコアの入ったURLみたいだな。
現在の日本語はとほほマークアップ言語みたいなものだと。 だから正統なISO/IEC 15445:2000を
>583 俺もだ...逝くか...
逝ってよし
しかし守るような株なのですか?
質問です。 <p> <object data="***.html" type="text/html" width="***" height="***"> <a href="***.html">なんとかかんとか</a> </object> </p> っていうのは、ストリクトではないんですか?というか、使用方法間違ってます? Lynxで見ると、objectの等価内容が見えてないんですよね。 <p> <object data="***.html" type="text/html" width="***" height="***"> 代替テキスト </object> <br> <a href="***.html">なんとかかんとか</a> </p> としなければいけないんでしょうか?
593 :
592 :03/03/11 03:51 ID:???
すいません。記述ミスでした。スレ汚し、スマソ
失礼いたします。 用語集、履歴書、年表、生物種の系統樹、化学周期表などをHTMLで表すには どのような書式を用いるのが適当でしょうか。 ご教授いただけましたら幸いです。
596 :
594 :03/03/11 15:04 ID:???
pdf以外で答えてもらえませんか? さもないと本当にあなたたちをAdobeの手先だと見なしますよ。
>>596 >さもないと本当にあなたたちをAdobeの手先だと見なしますよ。
面白い。ちょっと気に入った。
で、俺だったら用語集はdl、あとはtableを使うけど。
>>594 周期「表」、年「表」…。よってtable。用語集も場合によってはtable
系統樹は難しいな。視覚的なもんだし。 imgで描いてlongdescで説明か? 罫線と空白で無理やり作ってpreという手もあるが。
系統樹の構造のマーク付けだけならどうにか可能だと思うが 期待されるような整形はまず無理だろうね。
>系統樹 XHTML+SVG
系統樹ってのはRDFで表現できたりしないのかな?図にできるかどうかは別として
>>603 系統樹の中に出現する個々の項目はリソースなのか?まあそれでも構わんが。
RDFは基本的にメタデータを記述するものであって
データを記述するものではないと思う。
もちろん厳密な線引きなどないし
メタデータでないものの記述を禁止するものでもないのだが。
(´-`).。oO(何故 誰もGIFとかPNGとかJPEGとか言わないんだろう…)
(´-`).。oO(
>>599 ですでに画像という案も出てるんだけどな…)
(´-`).。oO(じゃあBMPで…)
(´-`).。oO(だから画像…)
俺、今ここ見て初めて「系統樹」と言う言葉を知りましたよ
610 :
Name_Not_Found :03/03/11 21:29 ID:hLPeDQ4J
(´-`)。o O(さっきからテレパシーで会話している香具師がいるな.)
画像だと 結局 代替テキストの問題が出てくるからだと思われ。 objectの中のテキストとか。
オレなら系統樹はdlで書くかな。ていうか書いたことがある。 <dt>が分類群,<dd>の中に<ul>放り込んで種小名を書き記した覚えがある。 確かこんなん <dl class="tree"> <dt>哺乳綱</dt> <dd><dl> <dt>食虫目</dt><dd>省略</dd> <dt>霊長目</dt> <dd><dl> <dt>ヒト科</dt> <dd><ul><li>ホモ・サピエンス・ネアンデルタレンシス</li> <li>ゴリラ・ゴリラ・ゴリラ</li></ul></dd> <dt>爬虫綱</dt><dd>省略</dd> <dt>硬骨魚綱</dt><dd>省略</dd> </dl> もしかしてstrictじゃない?
>>612 <dl> …… 3
</dl> …… 1
HTMLが担当するドキュメントの中に系統図や樹形図は入っていないので
(だって、図だもんよ)、どうしてもやりたければ、XMLベースのHTMLにして、
系統図(樹形図)用XML言語でマークアップするしかない(って、そんなXML
聞いたことないので、探してなければ独自作成ってことになりますわな)。
どうしてもHTMLの範疇でやりたければ、おれは
>>612 みたいにリスト系
要素をつかって、データの木構造を再現するが、それは既にリストであって
系統図や樹形図ではなくなっているのでNGか。
>>612 <dl>より<ul>使うべきじゃないか?
個人の解釈で、いろんなマークアップの方法があっていいんじゃないかと思うが。 系統図を広義のリストと解釈する人は、リストとして表現すればいい。 リストアップされた概念をわかりやすく見栄えを整えて並べたのが系統図だろう。
>>618 まず、オブジェクト要素で系統"図"(画像)を呼び出して、
オブジェクト要素の内容として
>>618 のようなリストを表記するのが
ベターかとおもた。
ただし、CSS非対応とかでも確実に系統図を表示しなければ意味が通じない
類の文章であればpreで罫線を駆使したベタtextの方が無難かも。
あと、リスト表示のばあい、一旦枝葉として別れてから、その先で合流する
系統図はかけないってのが弱点か?(SGML/XMLでは異なる親が同一の子要素
持つ事ができないし。)
>>619 まあ、系統“樹”なら子孫が交わることがないから、それでもいいと思われ。
621 :
Name_Not_Found :03/03/12 02:25 ID:kb1q0MFa
>>620 は知ってそうだけど,最近は原核生物じゃ割と頻繁にゲノムの交換をしているってのが定説だからな.真核生物でもやってるって言う人もいるし.
そういう系統樹を書く場合は一度別れた者がまた合流するってこともあるのよ.
系統樹は線の長さや方向や枝分かれの角度に意味があったりする場合があるので,そういう場合はulじゃ表現しきれないよね.
系統樹のXMLを作るか,SVGにするか,画像にするかって所かな.
ま,その辺が現状の限界って所だ.
>>621 >そういう系統樹
そういうのは“樹”ではないと、
>>620 は言い、
“樹”であれば子孫が交わる事がないと言っている。
誰も履歴書に触れないが、こんな感じ? <H1>履歴書</H1> <H2>名前</H2> <P>○○○○(フリガナ)</P> <H2>生年月日</H2> <P>昭和xx年xx月xx日生(xx才)</P> : : <H2>志望動機</H2> <P>〜〜〜</P> 学歴、家族構成とかはtableで
>>623 俺ならh2のところでdldtdd使っちゃうかもしれん。
<dl> <dt>2003/03/12</dt> <dd>文章文章文章文章</dd> <dd>文章2文章2文章2文章2</dd> </dl> <dl> <dt>2002/03/12</dt> <dd><p>文章文章文章文章</p></dd> <dd><p>文章2文章2文章2</p></dd> </dl> これは、どちらが正しいですか?ddを前者のように段落的意味合いで使用してもいいんですかね? やはり、後者の書き方の方が正しいと言えますか?
>>625 <dl>
<dt>2002/03/12</dt>
<dd>
<p>文章文章文章文章</p>
<p>文章2文章2文章2</p>
</dd>
</dl>
は選択肢に入らない? 自分だったらこうするけど。
根拠はないが dd を段落として使うのは気持ち悪く感じる。
>>625 どっちも使い方おかしくない?
dl使うなら
<dl>
<dt>2002/03/12</dt>
<dd><p>文章文章文章文章</p>
<p>文章2文章2文章2</p></dd>
</dl>
じゃないかな。
俺なら日記にdlは使わないでhnとp使うけど。
628 :
627 :03/03/12 16:10 ID:???
(´・ω・`)
>>625 仕様的にはどちらでもOKだと思うけど、個人的には、後者はくどいので
前者かな。
>>626-627 まさしく、それですね。
>>625 はどっちも使用方法がおかしいということに気付きました。
>>627 日記というか、更新履歴なんですが、直前にhn要素があるんですよ。
<h2>更新履歴</h2>
<h3>2002/03/12</h3>
<p>......................</p>
というのも考えたんですが、なんかしっくりこなくて、dl要素にしようと思いました。
しっくりこなかったのは、他で使用しているh2要素と更新履歴が同等のものと思えなかったのです。
逝ってる意味がわかりづらいですね。
お二人方、的確なアドバイスどうもでした。
>>629 そうなんです。html-lintばかりにとらわれてしまって、文書構造についての判断が混乱してます。
hn要素、dl要素など、Strictは難しいです・・。どうもでした。
>>631 なぜStrictで書くのか、という動機を再確認してみるといいと思う。
ふつうは「情報の利用性を高めるため」だと思うが、そうだとしたら、
「1.どちらも仕様に則っており」「2.情報の利用性に大きな差はない」
場合は、「どちらが正しいか」にこだわらず、個人的な好みで決めちゃって
いいと思う(だって、どっちも正しいわけだから)。
# それこそ、文字数が少なくてタイプミスしづらい方、とか、ブラウザの
# デフォルトスタイルで見やすい方、とかで決めちゃってもいいんじゃ
# ないかと。strictは手段であって目的ではないんだから。
>根拠はないが 萌え。
>>630 hnの方がソースの見た目的にしっくりきます。
>>635 あのな、100点だからといって慢心してはいけないのは余りにもガイシュツ。
さらに、お前は何を「問題がないのか」とおもってここに書き込んでる?
スレ住人を試してるつもりで、自分の無能さをさらけ出してるぞ。
>>635 てゆーか、そこ Transitional だし。
Transitionalって書いておけば、まあどんな風に書いてあろうが、文句の付けようがない。
こういうのもいわゆる受験の功罪ってなもんですかね?
<a href="
http://www.w3.org/TR/xhtml11/ ">
<abbr title="Extensible HyperText Markup Language">XHTML</abbr>
</a>
<abbr title="Extensible HyperText Markup Language">
<a href="
http://www.w3.org/TR/xhtml11/ ">XHTML</a>
</abbr>
お前らどっちが好みのタイプだっ
冗長とかtypoとか<a href="" title"">でいいとか中の人とか
そんな感じのアレのレスは4件以上はいらないからなっ
冗長 あと2件まで
>>643 >>632 個人的には後者。
前者だと、適用するCSSによっては、ハイパーリンクがはられていることがわかりにくくなるから。
略語であることがわかりにくくなるより、リンクがはられていることがわかりにくくなる方が不便だと思うので。
>>643 漏れは前者の方が好み、かなぁ。理由は特にないが。
一概には言えないけど、
<a href="
http://www.w3.org/TR/xhtml11/ ">
<abbr title="Extensible HyperText Markup Language">XHTML</abbr>1.1の仕様書
</a>
という場合もあるし、略語を表すabbrよりも「短い」リンクは、
リンクとしては多分使いづらいだろうから、自分なら前者に統一するかな。
abbrは使わない!
『「略語としてabbrでマークアップしたもの」をアンカーとする』と考えるなら前者 『「アンカーとしてマークアップしたもの」を略語と見なす』とするなら後者 僕は前者の例しか思いつけないから前者の方が好み
漏れは前者で統一。abbr以外のインラインのフレーズ要素もそうしてる。 「略語がリンク先を示す文字列である」というケースしか考えられない。
653 :
Name_Not_Found :03/03/13 20:57 ID:QHfEZTea
・
何を今さら
だからこのスレでも何度も同じような話しがループしてるでしょ
>>655-656 何でそう言う言い方しかできないのだね、君たち。
なんかこう・・・たとえそうだとしても、話をふくらませよ。
無理ですか?無理ですか・・・そうですか・・・
これだから頭の固い、無意味なことにばかりこだわって肝心なことがおろそかになりがちな連中は。
じゃ次の話題よろ↓
>>657 >これだから頭の固い、無意味なことにばかりこだわって肝心なことがおろそかになりがちな連中は。
そういう人達にネタ振りする君は何?
> これだから頭の固い、無意味なことにばかりこだわって肝心なことがおろそかになりがちな連中は。 何でそういう言い方しかできないの? これだから頭の固い(ry
あえて釣られてみるけど 過 去 ロ グ 読 め これだから春厨は。
見事に(数人だけど)釣れて、嬉しいです。
わざわざどうも
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ さて、不毛な議論でも続けましょう。 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
,,,,,,.........、、、、 ,,(::(:ヾヾ//ノ;;ノ;;;::ヽ,, l ;/  ̄ ̄ ̄ ヾヾ、 l ;l = 三 = .|;;;i l / ,--―'、 >ー--、 ヽl i^| -<・> | | <・>- b |. / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ||  ̄ | |  ̄ |/ | 不毛な議論ばかりしてると | /(oo)ヽ | < 君たちを訴えますよ! ヽ (⌒)___ノ / \___________ _, -r┤~.l. ニ /i、__ ( f | | ヾ.ー--/ |:::::::|:::::::: l.ヽ人八_ ,, ̄)\ |:::::::|:::::::::: `ー┬‐-ー' ̄
10スレにまでなると未出の話題は無くなってくる罠ですか。そうですか。
無毛とかけてるのか
しかしほんとネタないね。 前々スレあたりにいたUA至上主義のやつとかコテハン連中が懐しい。
そういや最近「腐」みないね
スレタイから X はずしたからこなくなったんだろ。
最近、個人サイトでもstrictに興味持ってる人増えてるから、ここの間口を広げりゃネタも増えるんじゃないかな? 単純な、簡単な、そんな質問でも答えるようにするとか。 でなきゃ仕様書嫁で全部解決しちまうぜ。
Strictは糞だよ〜 みんなStrictは糞だから使っちゃダメだよ〜 糞になっちゃうよ〜
677 :
Name_Not_Found :03/03/14 11:02 ID:aMY+Jjwm
解説サイトを読んでで思ったんですが、divで使いまくっていいんですか? 例えば、 <div class="level1" id="titleDiv"> <h1 id="titleText" class="unimportant">from DFJ</h1> </div> <div id="shortcutMenu" class="level2 unimportant"> <h2 id="shortcutMenuText" class="unimportant">ショートカットメニュー</h2> <ul id="shortcutMenuList"> <li><a href="#menu">メニュー</a></li> <li><a href="#introduction">お知らせ</a></li> </ul> </div> こんな感じですか。 なんでもかんでもdivで囲めばいいんですか? <h1>aaa</h1> <h2>MENU</h2> <ul><li>bbb</li></ul> こうやってあっさりしちゃいけないんでしょうか。
>>677 むしろ、あっさりしていてよいわけだが。
>>677 どういうCSSを使ってるかで判断。
<div class="level1" id="titleDiv"> や
<div id="shortcutMenu" class="level2 unimportant"> で
指定している CSS が h1 や h2 に指定すればすむものなら
divはいらない
例えば段組させたいならdivで囲うしかないでしょ。
訂正 段組になるような内容ではないわな(^^;
>>680 >どういうCSSを使ってるかで判断。
レイアウトでdiv使用の有無を決めてる時点で
strictじゃない。
684 :
Name_Not_Found :03/03/14 11:29 ID:aMY+Jjwm
>>678 じゃぁ解説してるサイトのソースはゴミゴミしててよくないってことでしょうか。
>>679 >不用なら何故付ける?
すいません、それを聞いてるんですけれども・・・。
>>684 よろしくない解説サイトも多いので鵜呑みにしないように。
むしろ解説サイトはすべて敵と思え。
あと自分も疑え
○○を疑えという人は信用するな
divを取っ払って構造がおかしくなるのは×。
DIVやSPANを使うのは、論理構造を考えていって 論理的まとまりが存在するのにそれに対応する要素が使用しているバージョンのHTMLになかったとき。 例えば、 <h2></h2> <p></p> <p></p> ってのがあったとき、HTML4.01strictではSECTIONが使えない、 でもこれらは論理的まとまりが強い(または形成の為だが十分に論理的意味合いを見出せる)と思ったとき <div class="section" title="****" id="????"> <h2></h2> <p></p> <p></p> </div> ってやってやる。そんな感じで私は使ってる。
結局、著者が必要だと感じたときが必要なとき。 書いてる本人が必要な構造を意識できていない段階で見よう見真似で使ったって 誰にとっても役に立たない変な構造や冗長な構造になるのがオチ。 最初はCSS目的だっていいじゃないか。 色々な使い方をすることでそのうち解ってくるものだ。
<div class="level1" id="titleDiv"> <h1 id="titleText" class="unimportant">from DFJ</h1> </div> <div id="shortcutMenu" class="level2 unimportant"> <h2 id="shortcutMenuText" class="unimportant">ショートカットメニュー</h2> <ul id="shortcutMenuList"> <li><a href="#menu">メニュー</a></li> <li><a href="#introduction">お知らせ</a></li> </ul> </div> じゃなくて <div class="level1" id="titleDiv"> <h1 id="titleText" class="unimportant">from DFJ</h1> <div id="shortcutMenu" class="level2 unimportant"> <h2 id="shortcutMenuText" class="unimportant">ショートカットメニュー</h2> <ul id="shortcutMenuList"> <li><a href="#menu">メニュー</a></li> <li><a href="#introduction">お知らせ</a></li> </ul> </div> </div> こうかなー。
>694 全部タイトルという扱いなの?変じゃない? 前者のままでいいと思うけど
h1を包含するdivとh2を包含するdivが同レベルなのは、変かなと。 h2を包含するdivはh1を包含するdivに包含されるべきかなと。 で、h1を包含するdivってばbodyなんじゃないかと。
>696 h1が2つあり得るのなら>694でいいんじゃない? あとはaddress部分だけを分けるとか
>>696 自分の文書のローカルルールなら好きにやってくれって感じだが
一般論として語っているなら相当な思い過ごしかと。
ISO-HTMLのDIV1〜DIV6をイメージしながらマークアップする事でDIVの使い方が分かってくるような気もする。 少なくとも俺の書くHTMLでは出番が無いな。本文はHnとPで殆ど足りる。
>697 h1が2つなんてありえないと思ってましたが…2つあってもいいの?
新しい仕様書はそんな感じなのかな。 CSS3やWAIやXMLとかの仕様書見て回ったけどh1は一回しか出てこない…
W3C仕様書といえば、ほぼ全ての仕様書にあると思われる "W3C Recommendation 31 May 2001" (まあ日付は色々あるだろうが) が h2 としてマークされてるのが漏れは禿しく違和感あったりする。 それってどの範囲についての見出しよ?という感じ。 やっぱり h1-6 は章節構造に直結するものではないなとつくづく思う。
<h2 id="slogan">Leading the Web to its Full Potential...</h2> これも見出しなのか?
>>707 スローガンだしなあ。見出しじゃないの?
日付をマークアップできる要素が欲しい。
で、日付をマークアップする要素がインラインだったら どのブロックに包含させるかで議論が起きる、と
datetime属性が汎用属性だったら便利なんだけど
>>711 XHTML 2.0 では汎用属性になる予定だが。
とりあえず、
>>691 みたいなのは間違ってるから鵜呑みにするなよ。
ああいうのは div とか span は css のためだけにあるって思ってるから。
table 嫌悪しすぎてすべて dl で記述しようとかしだすような
典型的な勘違い。
714 :
Name_Not_Found :03/03/15 02:46 ID:C1j/UMAA
女の子をマークアップできる要素が欲しい。
君を俺色にマークアップしたい・・・
<sexy>胸</sexy>
<small>チムポ</small>
<blink>挿入</blink>
_, ,__ ('д'*)
>722 彼女のDTDにその要素は無いので無視されます。
<p style="text-decoration:blink">乳首</p>
(;´Д`)l \ァ l \ァ
>725 おfella以外無効。
<human sex="female" age="14" /> ♪ ヽoノ ( ヘ >
,' ' o (ヽ ><human sex="female" age="14" />
(´ヘ`;)タイヘンソウデスネ
(´ヘ`;)ヘンタイソウデスネ
未だ完璧なブラウザってないんだよなぁ……
733 :
720 :03/03/16 02:30 ID:???
<body color="#ffeedd" class="sexy"> ( . ( . ) ) ( | Y ) | | ノ </body>
IEとかホントやめてくれって思う解釈するよな まあ糞ネスケほどじゃないが
>>732 Amayaが(・∀・)あるじゃないか
冗談でも使おうとは思わないけどな。
完璧な仕様だって未だにないし。
将来を見てストリクタしてるけど その将来ってのが生きてるうちに来るのか疑問
せっかく頑張って考えたものが変な使われ方してるの嫌じゃん
>>735 Amayaが完璧だと本当に思っている?
CSSの解釈, かなりおかしいぞ.
お前の解釈の仕方、かなりおかしいぞ
Amaya厨ハケーン!
最強は脳内レンダリングってことで。
まぁ、なんだ、Amayaを知ってるようなマニアックなやつは、 その実装状態も確実に把握してるわな。
745 :
Name_Not_Found :03/03/17 02:46 ID:1ICbhdOa
駄すれ化してない?
ネタがないんだよ
質問者(ゞ´∀`)ゞカモンベイベェ
お言葉に甘えて質問をば。 みなさん、emとstrongはどういう風に使い分けていますか。
749 :
侍魂 :03/03/17 17:51 ID:???
オチはstrongで、他のフォントいじりはemです。
じゃあ次
abbr と acronym の省略前の語を title 属性に入れるって嫌じゃない? なんで汎用属性を使うのかなと。
display: tableレイアウトしてもいいですか?
(・∀・)イイ!
>>748 XHTML 2.0 では strong を廃止して em に一本化しようかという話も出ています。
参考まで。
でもまだドラフトだし
757 :
Name_Not_Found :03/03/18 02:49 ID:7hwCKn8c
strong と em に違いはないから、どっちかに一本化した方が良いよ。
ageちまった。すまそ。
違いなくはないだろ。em より strong の方が強い強調。 ただ、「強い強調」なんて em のネストで表現すりゃ済むことだから strong を廃止にしてもいいんじゃねーかみたいな話が出てるんだと思うが。
strongのほうが残って欲しい。 emよりstrongの方が好き。こうなんていうかstrong要素を記述してるときの自分が好き。
CSS的には em em,strong{} みたいな感じでemのネストとstrongを等価として あつかっちょります。その上で、 「重要、凄く重要」なら <p><em>重要、<em>凄く重要</em></em></p> 「凄く重要」なら <p><strong>凄く重要</strong></p> と言う感じで。 後者は<p><em><em>凄く重要</em></em></p>でもいいんですが、二重のemが 同時に始まって、二重のemが同時に終わるのもなんか間抜けなので。 #ちなみに、XHTML2.0でstrongが廃止されたらそういうものだと割り切ってemネストの予定
>760 俺が一番セクシー、か。
strongって太字でしょ、なかったら困るよ。
>>761 以外に質問。
<em><em>と<strong>ってどっちが強いの?
765 :
○○ :03/03/18 08:29 ID:???
strongが太字表示だからどうの、とかemが斜体表示だからこうの、とかは、 Strictな視点からみて、どうでもいいことではなかろうか。
<strong> <stronger> <strongest>
>764 <em><em>うんこ</em></em> = <strong>うんこ</strong> ってことじゃないの?
<em><em> = <em> だと思っていた
要素を重ねれば意味合いが強くなるって 仕様上で言及あったっけ? ウォーズマンのベアークローの理屈みたいなんだけど
strongだろ
>769 em=strong
いっそのこと、emとstrong統一しろよ。>W3G em < strong em+em < strong em+strong < maccho ということでmaccho <p>昨日知り合った彼女の名前を聞いたところ、なんと<maccho>敏夫</maccho>だったのです。 又は、 <maccho type="text/html" data="./docs/main.html" width="500" height="400" id="fuck-box" class="common"> <p>〜</p> </maccho>
W3爺
なんでCとGを間違えんねんな。
そうでしょうね。
<maccho></maccho> これもわざと? 正しくは'macho'かと(西語)
ほかの部分よりも弱いという逆の強調をしたいのですが。 強調といわんか 弱調。
重要度みたいのを属性で表せたらおもしろいかもね
つまり<em pri="-1">オタは</em>逝ってよしと。
強調であるか否かを <em> で表して、 強調の度合いについてはスタイルシートを用いるのが至当と思われ。
<sis pri="12">お兄ちゃん</sis>
CSSは強調の度合いというものを全く関知しない。
?
>>784 <em class="slight-emphasis">ちょっとだけ強調</em>
とか
<em class="intense-emphasis">すごく強調</em>
なんてやるよりは、すなおにemとstrong使い分けた方がいいと思うが。
適切な要素があるのに、class属性でなんとかしようとするのは、
<div class="heading">見出し</div>
とか
<div class="list">リスト</list>
なんてやるのとあまり変わらないと思う。
>>787 >>786 が言ってるのは、CSSは、文書のプレゼンテーションを指定するだけで、
「強調の度合い」のような、文書の論理構造を指定することはできない、と
いうことでしょ。
インライン要素にdisplay : block;と指定しても、その要素が実際にブロック
要素になるわけじゃない、とか、そういうのと同じ理屈で。
<em1> <em2> ……
791 :
788 :03/03/19 12:58 ID:???
>>788 「強調の度合いについてはスタイルシートを」でちょっと先走ってしまった
けど、もちろん、class属性をセレクタにする以外の方法(style要素とか
style属性とか)も好ましくないことに変わりはない。
あと、
<div class="list">リスト</list>
は
<div class="list">リスト</div>
の間違いね。
<big>とか<small>って使ってる香具師いる?
すとりくたーはあまり使わないとおもうけど
神崎氏は使ってたような
>>791 3段階以上の強調構造が存在する場合は、どうするのが好ましいと思ってる?
796 :
791 :03/03/19 16:37 ID:???
>>795 3段階以上の強調構造が必要なのって、どういう場合?
Mark is <em>tall</em>. Hyper is <strong>taller</strong> than Mark. Text is the <???>tallest<???> of the three.
強調するところを見出しと考えてhnで。
>>797 Mark is tall.
Hyper is <em>taller</em> than Mark.
Text is the <strong>tallest</strong> of the three.
>>797 強調する理由は?
er、estというのと「その言葉を強調したい」というのはまた別だと思うんだが。
(em/strong)にclassを与えるか、それともネストするのか──って質問なのかな、これは。
strongは長いからきらい。em2にしてほしい。 以下em3,em4...
<rm level="7"></em>
強調を示すような属性を汎用属性にしてくれればいいのに
「ここ笑うところですよ」って意味でem使うのダメ? 例) 昼なのに<em>ヨルダン</em>
いいんじゃない?
>>796 文章中の重要な語句を強調する際に
試験に出る頻度で2段階よりも細かく区別したい時とか。
というか、どういう場合とか強調する理由とか個々の事例ではなくて
2段階あれば充分という前提が
どんな場合でも通用すると断言できるのかと聞きたい。
「弱調」要素が欲しい。テキスト系でしか需要無いかも知れんが。
デフォルトの文字と違うマークアップであれば、 意味を弱くしていても他より目に付くのは当たり前。 色が薄いとか文字が小さいとかは、ただ読みにくいだけでやっぱり目立つ。 ソース見れば「ここは弱くしてるんだな」って思われて逆に目立つ。 だから強調の一種と考えてemを使う。emが嫌ならspanでも。 そんでclass振ってCSSで見た目を変える。 口からでまかせヒャッホー。
弱調は強調の一種と言う人が此処に限らずちらほらいるが、それは違うだろ。 全てのマークアップが強調か? 違うだろ。言わば、意味付けだろ。 それに、ちょっと前にも書かれている通り、CSSは何の関係もない。 理解できていない奴は、とりあえず、CSSを忘れろ。不毛だから。
弱調なんて日本語あったかな
全てのマークアップが強調とは思わないが 全てのインライン要素はある種の強調だろうと思う。
>>813 「ある種の」じゃアバウト過ぎてわからん。
まぁ、今のHTMLじゃemの逆の要素が無いから議論したところで無駄だと思うけどね。 それでもマークアップしたいって言うなら「強調の一種」と考えるしかないんじゃない? そんなに弱めたいなら「弱い≒無い」って考えてdelでも使って消しとけば? にくまん食いたくなってきた。
マークアップ自体が強調。 でなければ、プレーンテキストで充分。
>>816 それならまだ理解できるんだけど、
>>813 の言う
「強調でないブロック要素」って一体なんじゃろ
819 :
Name_Not_Found :03/03/19 21:48 ID:26l5e2jo
820 :
813 :03/03/19 22:02 ID:???
>>817 間違えた。強調だと思うのはインライン要素じゃなくて %phrase; の要素。
%special; とか %formctrl; は強調とはわけが違うなと思う。
>「弱調」要素が欲しい。 筆者が「弱調」だと思っている文章も、 実は注釈でしかなかったり、コメントでしかなかったりする。 ならば、「弱調」としてのマークアップよりも、 注釈やコメントとしてのマークアップを考えた方がいい。
>>809 >>815 現行のHTML/XHTMLでも、弱めたいところ以外のテキストをすべて強調すれば
できないことはない。
不毛な机上の空論だが。
>821 >822 ハゲドゥ
“弱調”をするんだったら、 <small class="weak"> とかかなー
誰か、<acronym title="Adult HyperText Markup Language">AHTML</acronym>のDTD書いてください。
xml-stylesheet 処理命令って type 属性が #REQUIRED になってますけど、HTML の link 要素では省略可だったのに 何故変更されたのでしょうか。 # スタイルシートのネゴシエーションは # しちゃいけないということなのかな。
>>825 HyperTextはこれで一つの単語だから、
acronymとするよりabbrの方が適当だと思われ。
>>824 弱い、ってのはつまり小声で言うようなものかな、と思い、漏れはクラスwhisperにして、薄い色にしてますが。
weakの「弱い」はちょっと意味が違うような気がするんだけど。
ところで弱調?ってのは例えばどういう風に使うの?
>>832 会話調のくだけた文章などで、大きな声ではいえないような部分
(内緒の話とか、オチとか)に使う……かなあ。
<p>正解者は、漏れなくハワイ旅行にご招待!
<small>……ただし自費で。</small></p>
例文のsmallでマークアップされてるところみたいなの。
/ ̄ ̄'' -、 ( / ) ヽ i r-,,,, /,,,, ) / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ( >| ● ●// | 今ならDVDが付いて198,000円 `‐| U /ノ < <small>ただし送料はおまえら負担</small> \ ━ ,/ \____________ (((O⊃> \ 'oヽ |,,,,,,∧| / ∧ \ / / ヽ ヽ ト-< |_/''┐ ヽ='' `=='
>>833 自分もそういう感じで「弱調」使いたいと思ってますた。
弱調の話題の最中にすまないんですが、addressの書き方で悩んでいます。 フッタとして著作権表示とaddressを書きたくて、でもなるべく短くしたいので、 <address> <a href="サイトURL">サイト名</a>© 2003 <a href="mailto:メールアドレス">ハンドル</a> All rights reserved. </address> ってまとめて書いていますが、これって悪いですか?
>>833 漏れならその場合
<p>正解者は、漏れなくハワイ旅行にご招待!
<ins title="あまり大きな声じゃ言えないけど・・・">……ただし自費で。</ins></p>
かなあ。
>>834 わろた
>>836 > <a href="mailto:メールアドレス">ハンドル</a>
ニールセンはハンドルや名前にメールリンク張るのはよろしくないと言ってたな。
ま、それでいいんじゃないの?
ところで寂聴?ってのは例えばどういう風に使うの?
>>839 反戦っつってる奴って代案ださないで叫んでるだけだよな。
先制攻撃されて知人や身内が次々と死んでいっても「攻撃してはダメだ」とか言うんだろうか?
>>842 1.戦争の悲惨さを知ってるから。(外交・海外訪問で戦地痕を訪問など)
2.日本は非軍事国家なので攻撃されてないと思ってる。
3.ある団体・組織の影響力が強い。
4.偽善者。
俺は1が理由だけどな。
>>843 気持ちを無視するわけではないが、「反戦」と吠えることが事実上戦争の悲惨さを回避できるわけではないのも事実だろ?
>>838 予告なくmailto:がって話じゃなかった?
まあ、名前→人物紹介でそこにメールアドレスが記載されているのがかなり丁寧だとは思うけど。
>>845 Top Ten Web-Design Mistakes of 2002 (Alertbox Dec. 2002)
http://www.useit.com/alertbox/20021223.html > Mailto links should be used on anchors that explicitly indicate that they're
> email addresses, either by their format (
[email protected] ) or their wording
> (send email to customer support). Don't place mailto links on names; clicking
> on people's names should usually lead to their biography.
てなわけで名前にリンクは張るな、ボケと。
847 :
839 :03/03/20 12:14 ID:???
839は無関係だろ。
850 :
836 :03/03/20 15:19 ID:???
>>838 ,845,846
ありがとう!ではaddress内にCopyrightを纏めて書くことに問題は無いんですね?
名前にリンクは張らないことにします。1つ勉強になりました。
>>849 いや、戦争もスレ違いだけど寂聴もスレ違いだから。
いや、寂聴は弱調の変換ミスだろ。
瀬戸内 寂聴
dl要素の内容モデルは、dt要素もしくはdd要素に限られます。 とのことですが、 <dl> <div></div> <dt></dt> <dd></dd> </dl> こういうの駄目ですよね?
駄目ですね
>>855 <dl>
<dt></dt>
<dd><div></div></dd>
</dl>
これなら、よろしいざますわよ
859 :
842 :03/03/21 09:52 ID:???
>852 ごめん真剣に「弱調」の誤変換だとは気付かなかった。 スレ違いだとわかってながら、厭戦ムードに対し黙ってられんかってな。すまん。
誤変換じゃなくて脊髄便上ネタかと
862 :
578 :03/03/21 11:54 ID:???
誤変換だと思ってたけど、>860だとは気付かんかった。そうか。 ところでスレ違いだがWTCの遺族が早くから反戦を訴えていることを付しておく。
578はCookieミス。汚しスマソ。
864 :
Name_Not_Found :03/03/21 12:47 ID:SErWnXgO
W3Cの遺族?
W Three C
>>861 あ、既に Errata で訂正されていたんですね。
不覚にも見落としていました、
御指摘感謝です。
>>867 うにこーど使ってxml宣言はずしましょ!
>>869 うにこーど、uni-codeのことですか?
.htaccess使うのかな?とにかくググってみます、ありがd。
>>867 上位のプロトコル(HTTPとか)で文字コードが指定してあれば
encoding="〜" は不要、とされている。
その上位のプロトコルが文字コードとともに「HTML文書だよ〜ん」って 言ってきてたりすると何だかなあと思う。 妥協が必要な部分は掃いて捨てるほどあるので別にいいんだが。
piroのサイト、OperaでJavaScriptONにしていくと落ちる・・
Opera7
>>873 少し変えてみました。まだ落ちますか?
まだ落ちるとなると、CSSのexpression()のせいだろうか。Operaってexpression()を解釈するんだろうか。
>>875 piro本人?
今確認したけど、改善されたようだ。グッジョブ
しかし、Limeted適用させると、ちょっと酷い。
質問です a要素にはtarget="_top"って指定した方がいいんですか
>>879 Transitionalなら「してもいい」
Framesetなら「target必須」
Strictなら「非推奨」
> Framesetなら「target必須」 > Strictなら「非推奨」 えええっ!?
displayプロパティは自由に使ってもいいんですか? インライン要素に display:block とか。 レイアウト目的の display:table; / display:table-caption; とか。
>>884 ... ..- .-. . -.-. .... .. --. .- .. .- --. . .-. ..- -. .- -... --- -.- .
スタイルシートってレイアウト目的以外の何者でもないと思うが…
音声ブラウザのspell-outを考えて abbrを使い分けている、とかそういう人っている?_
>>888 get...
それ以外にも、例えば、IEEE1394の数字部分にクラスをつけたり、
音声ブラウザの為のCSSを用意している人っているの?
突然だけど顔文字の使用についてどう思う? altが用意できるだけ、画像にした方がましかな? どっかのスレに登録されている顔文字だったら ホームページリーダーでも読んでくれるとかいう話を聞いたんだけど
>>890 もとがテキストだから、「順位」は
テキスト >> 画像 になると思われ。
でも、特定の環境に依存するAAはどうなんだろう。
等幅ならともかく、2chなんてMS Pゴシック/モナーフォントだけだし。
1行程度の顔文字は記号の羅列だからspea-punctuation:none;で読まないようにして、 titleに顔文字と分かる説明を入れてる。 複数行になるAAは画像にしてる。いちいちフォント指定するのが面倒だし。
>>890 リーダーで読めるかどうかはStrictと無関係。
>>891 AAの類は画像にした方がいいってWAIに書いてあったと思う。
どうしてもテキストでそれを表現したい場合は、音声ブラウザ
のためにAA部分をスキップできるアンカーを設置しておく…とか。
890じゃないが、自分も顔文字について考えていたところでした。
>>892 (・∀・)イイ!自分もそうさせてもらうYO!
顔文字はイクナイ!
.顔文字 { font-family: "MS Pゴシック"; } .イイ!:before { content:"(・∀・)"; } <span class="顔文字 イイ!">イイ!</span> ...冗談だってばよ。
>>896 「顔文字」は物理的なクラス名なので、「感情」などの論理的なクラス名にするのが望ましい。
aural にcontentってあったっけ?
なんかValidatorで警告された記憶があるんだけど。
それだったら
>>896 は aural ではcontentが読まれないからイイかも?
'content' Value: [ <string> | <uri> | <counter> | attr(X) | open-quote | close-quote | no-open-quote | no-close-quote ]+ | inherit Initial: empty string Applies to: :before and :after pseudo-elements Inherited: no Percentages: N/A Media: all Media は all とされてるね。
>>896-899 つまり、
@media screen,tv,print{
.感情 { font-family: "MS Pゴシック"; }
.イイ!:before { content:"(・∀・)"; }
}
<span class="顔文字 イイ!">イイ!</span>
ってことか。
901 :
900 :03/03/23 20:29 ID:???
自己レス @media visual{ } のほうが適当だば。
902 :
900 :03/03/23 20:47 ID:???
@media screen,tv,print{ .感情 { font-family: "MS Pゴシック"; } .ショボーン!:before { content:"(´・ω・`)"; } } 次スレ立てなきゃならんと思って、テンプレ整理してたら ここって<em>950</em>が立てるのな。<span class="感情 ショボーン">ショボーン</span>
903 :
Name_Not_Found :03/03/23 23:12 ID:0kALodEP
いろいろ調べたところ、どうやらフレームはあんまり評判がよろしくないようで、 各ページ毎に上部に小さなメニュー(タダの画像と文字に各ページへリンクを貼ったものですが) を置こうを思うのですが、レイアウトはスタイルシートで指定するとして タグは何を使ったらいいのでしょうか? H6とかを使用していいのか、それともDIVなどを使うだろうか・・・。 教えてください。
904 :
Name_Not_Found :03/03/23 23:15 ID:eGouO59+
>>905 幸せに慣れそうです。ありがごうといました。
907 :
Name_Not_Found :03/03/23 23:38 ID:0kALodEP
>>905 あんまり幸せにはなれませんでした・・・・。
liかdivですね・・・。
>>907 幸せに慣れてしまっては幸せにはなれませんよ。
で、どうしたら幸せになるんだ?
>>908 結局どっちかよくわからないのであんまり幸せじゃないで
幸せねえ...気色わるー
スレッド1からスレッド10まで読み返せば幸せになれる。
カスイケスレかなんかでいいと思うサイトを参考にしたら? 俺も最初はそうやって覚えていった。
913 :
Name_Not_Found :03/03/24 09:06 ID:g9IPjORP
マークアップに関して「いいと思う」をあまり知らない状態でどうやって判断するのか。
<html lang="ja"> をいれているばあいって、 <meta http-equiv="Content-language" content="ja"> は要らないですか?
不必要です
>>914 あってもいいと思う。不安なら書いとけ。
HTTPヘッダとHTMLは別物だから書いた方がいいんじゃないかとも思いつつも
HTTPヘッダじゃなくてmetaのhttp-equivに書くべきかと問われると悩ましい。
本物のHTTPヘッダでContent-Languageを出力して、なおかつ
html要素のlang属性を明示するのがベストなんだが。
不安なら両方書いとけ、ということで。
scope属性やheaders属性、axis属性がいまいちよく分からないんですが、 どなたかくわしく教えてくださりませんか?
それらは使ったことないけど神崎さんの本で覚えた
くださ“り”
>>916 Apacheのデフォルトの設定ではjaという拡張子をつければ
Content-LanguageをHTTPヘッダで出力できる
924 :
Name_Not_Found :03/03/25 00:50 ID:BYEWfszA
アクセスカウンタ(画像)に付けるタグはなんぞや? <var><img src="./count.cgi" width="128" height="16" alt="counter" title="You're 12345th visitors."></var> とか?(SSIでタグごと表示)
と、思ったけど・・・ たかが 466 しか引っかかってないってことは・・・ やはり“い”の方が正しいんじゃない?
こんなところで古文の勉強ですか。
さすがstrictスレ。
古文じゃないだろ。
検索件数で判断しようってのはStrictスレっぽくないな。 StrictなHTMLと不思議マークアップはどっちが数で勝ってると思ってるんだ?
駄文だろうな。
板違いを続けて申し訳ないのですが ら行五段活用動詞「くださる」の連用形「くださり」の音便が「ください」じゃないの? >924 わざわざマークアップしなくても,と思う で,<var>ってのは変数名なんかに使うんじゃなかったけ? だとしたらカウンタの中身に使うんじゃなくて <var>訪問者数</var>とかそういう感じではないかと (やはりマークアップする意味がなさそうだが)
>>931-932 でもこの場合は「日本語の使い方」の問題だからなあ。
なんでもかんでも「strictスレの考え方」に当てはめるのはどうかと(藁
で、「日本語の使い方」はスレ違いと。
>>933 よーわからんが、どっちが正しいんだい?
936 :
918 :03/03/25 01:25 ID:???
>>933 >ら行五段活用動詞「くださる」の連用形「くださり」の音便が「ください」じゃないの?
納得しました。
で、結局どうなのでしょうか。
仕方ないな… のあたん、よろしく!
理屈でいったら“り”だけど、 世間一般では“い”が使われているってことだろ。 つまり“い”が正解。
「い」が正解って琴か?
scope属性、headers属性、axis属性を実装しているブラウザってあるんですか?
新スレ用のテンプレ貼ってもいいですか?
あ…思いっきりウソ書いたっぽい. 広辞苑によれば 「ください」:(「くださる」の命令形「くだされ」の口語形) だそうなので,音便とかそういうのは関係なく「ください」という言葉だと思うべきだね.
『い』でFA
『い』でFA では次の話題に逝きましょう。
945 :
900 :03/03/25 01:50 ID:???
そこまで逝かずに落ちるなw
まあ950くらいは↓
ゲプー
1時間経過しても立ててないのか?
953 :
900 :03/03/25 14:25 ID:???
立ててきまぷ。
954 :
900 :03/03/25 14:33 ID:???
955 :
Name_Not_Found :03/03/25 14:38 ID:BYEWfszA
>>933 回答有り難うです。
でも無しにすると、body直下に来ちゃうので、Hにでも囲んでおきます。
>>955 hnでは無いと思われます。
私ならpを使います。
>>924 altとtitleの内容は逆のほうがしっくりくる。
それと、SSIならテキストカウンタにすればいいのでは。
>>924 >>955-956 というか、varもインライン要素だから、body直下に置けないのだが。
一種の段落と捉えてpとする人と、段落ではないと捉えてdivとするのが
一般的。
「項目がひとつしかないリスト」と捉えてulでマークアップする人もいる
が、少数派。
>>957 の助言通り、altを"You're 12345th visitors."とするならば、
段落と捉えやすくなるので、pでマークアップするのが妥当かな。
>>957-959 詳しい解説ありがとうです。
<var>には、 VAR {display:block;} なんてのをかましていたので反省することしきりです。
altとtitleを入れ替えて、<p>〜</p>で出力するようにしてみます。
埋め
梅
踏め
夢
組め
頭悪い梅方だなー
て〜やんでぇ!!
ウメェ〜!
ッシュ!
楳
973 :
Name_Not_Found :03/03/26 16:18 ID:si7Y8+cA
あげ
生き埋め殺人事件
975 :
Name_Not_Found :03/03/26 16:58 ID:si7Y8+cA
って? ↓はいアホの反論
なんでだろ〜
ここから梅はボケ・ツッコミのみとなります。ご了承下さい。
うめ。
>>979 なんでやねん。
このスレの感想:あー面白かった。
ありがとう、私たちを無視してくれて。 あなたの決断に反対する態度を明らかにしたすべての人を除け者にしてくれて。 なぜなら、地球の未来は除外された者たちのものだから。 -- パウロ・コエーリョ
神崎キモい
いかそうめん ↓
「ん」?
―――――――――――――――― 鏡 ノノノ ('A`) ちょっとパンク風にしてみた ノ( ヘヘ
それがどうした
埋め
埋め立て
楳
梅
埋め
埋め
うめ
梅
埋め立て
999
1000
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。