1 :
Name_Not_Found :
2006/08/06(日) 21:59:45 ID:m7NkI4ZY
おつ
区切ったものが結果としてデザインに利用できるのと デザイン用に区切ったものに流し込むのは違うぞ と呼び寄せてみるテスツ
でも両立も出来るから問題なくね?
両立しててもデザインの為に(略 って言い出す奴は多い と更に煽ってみるテスツの真似
>(略 この書き方が夏厨っぽいw
厨は(ぁとかだろw
w ← そもそもこれがStrictじゃない
Strictにwを書くとしたら(笑)か?
(私は笑っている) だな。
<abbr title="わらい">w</abbr>
さとみちんがやってたな。 <abbr title="ワクワクテカテカ!">wktk!</abbr> しかし「テカテカ」の意味がよくわからんからどうしようもないw
スレのキモ度が増してる… 水分をください! 水分をください! 水分をください!
>>6 >区切ったものが結果としてデザインに利用できる
確かにその感覚は大切だと思うけど、
本気で他の利用方法を一切考慮せずにそういうマークアップになるんだとすれば
(論理的に)装飾華美なHTMLを書いているに過ぎないと思う。
そもそも、なんで区切るのか。
<div class="section">とか要らないでしょう。
それがあることでHTMLとして何の得がある?
UAが意味を理解できないdivやspanを入れたところで自己満足に過ぎない。
langを設定するとかの使い道はあるけど、classだけのdivやspanに意味は無い。
時々、<span class="date">2006/08/07</span>とするべきか?
みたいな問いかけがあるけど、あれも変な疑問だと思う。
そんなこと書いたって、(HTMLだけの)UAを介してアクセスする限り基本的に何の情報も得られないし
その調子でマークアップしていったらきりが無い。
じゃあ、何故divやspanを使うのか。
人間が見て理解するという利用方法も皆無ではないものの、あまりやらないだろう。
それに人間のためだけなら極端な話だけど、コメントとして書き込んだって十分機能する。
なら何故かと言うと、それはHTMLの要素だけでは表現できない構造を機械的に利用するためだと思う。
HTMLを機械的に利用する存在と言えばCSSやJavaScript。
それ以外にも自分なりにhtmlから情報を取得するプログラムを作ったっていい。
それらでの利用を前提にするからこそ、<div class="section">や<span class="date">が意味を持つ。
必要だ(利用する可能性がある)と思ったらマークアップすればいい。
マークアップ!マークアップ! これはもうダメかもわからんね。
<div class="section">はともかく <span class="date">はすでにこのスレで否定されとるがな。
<dc:date>
>>22 ><span class="date">はすでにこのスレで否定されとるがな。
別にこのスレの意見に反対しているつもりもないけど。
ただ、そういう疑問を抱く人は、divやspanを使うということがどういうことなのか、
自分の中で全く説明できていないのだろうと。そういう話。
この話題が変わっても続けるしつこさはいつもの人?
>>23 ってXHTMLなら文書中でつかってもおkだよね?
<dc:date>
Strictなんて、みんな(Lynxとか、音声ブラウザとか)が幸せになれる方法にすぎない。 逆に、みんなが幸せになれるなら、<span class="date">でも何でも使っていいと思った。 <span class="date">なんかは、幸せになれるかどうかはともかく、不幸せになることはないだろうから やりたい人はやればいいんじゃね?と思った。
<sman ashita="date"> 幸せでごめんなさい。
幸せになるならいいけど、無駄に使ってデータ量が増えると不幸だな
幸せなんて、人それぞれだから。
XHTML2.0なら <span property="dc:date">...</span> でおk。
2.0になったら徳も何も全部section入れるんだから今からdivセクション入れとけー【泥縄】
デザインデザイン言ってるけど、デザインの意味わかってるのか? 賞とるような「デザイナー」は大抵アーティストでしかなく 「デザイン」はないがしろであることが少なくない。
流し込む人ですから
>>36 それは移行が楽になるからってだけでしょう。
機械的処理を見越してるに過ぎない。
>>37 見栄えでもアートでも自分の好きな単語に置き換えればいいと思うよ。
>見栄えでもアートでも ・・・・・・・・・・・・・・・・・・・・・・・・ちゃうやろ。
そこは何でもいいって言いたかったんだよ。 少なくともdivの使い方とは関係ない。
すげー誤読王。
>>20 > 本気で他の利用方法を一切考慮せずにそういうマークアップになるんだとすれば
必要な論理構造の程度というものに応じて考えればいい。
早い話が問題の切り分けが出来るかどうかだ。
そして、「こういうデザインにはこれだけの論理構造が必要」という
方針で論理構造を考える、とこのスレで発言するのは、問題の
切り分けができてない。
なぜなら、デザイン云々はスレ違いで、必要とされる論理構造が
どの程度か、というところまでしかこのスレの範疇には含まれない
からだ。
「時刻を時・分・秒で区切る構造が必要だから、
<span class="time">
<span class="hour">16</span>:
<span class="minute">53</span>:
<span class="second">41</span>
</span>
とマークアップする」
と言うのはスレ違いじゃないが、
「時刻を時・分・秒で表示したいから
(中略)
とマークアップする」
と言うのはスレ違いだってことだ。
>>43 自己レス
誤 > 方針で論理構造を考える、とこのスレで発言するのは、問題の
正 方針でマークアップを考える、とこのスレで発言するのは、問題の
もう何度目の説明だろうね・・。
一応、言っておくけど自分は前スレの人じゃないよ。
デザインの為に区切るとも言ってない。
「その感覚は大切」といったことが紛らわしかったのなら申し訳ない。
で、
>>43 だけど何で時・分・秒で区切る構造が必要なの?
少なくとも、いわゆるブラウザでCSSも当てずにJSも使わずに表示するだけなら必要には思えない。
HTMLの仕様上では、何かの構造を表す以外に何の意味もないんだから。
で、そんな冗長な記述をすることがStrictだとも思えない。
>必要とされる論理構造がどの程度か
って言うのは何にとって必要なのかが明確でなければ話にならない。
時間だけをマークアップすればいいのか、時・分・秒までマークアップする必要があるのか、
利用方法が分かってなければ指摘もできないでしょう。
>>43 どっちも問題ないでしょ。
マークアップには解は一つじゃないんだし、そのマークアップが適切なものであれば、
目的がなんだろうとわかりようが無いし。
あぁ、そもそも「時・分・秒まで区切る構造が必要」とまで決まってなければ話題にも出来ない? ならスレ違いだね。申し訳ない。 でもスレ違いであることとStrictじゃないことは別問題だと思うんだけど。 変に過剰反応しているように見えて仕方ない。 そしてわかってる人のそうした反応に、 分かった気になってる人がつられているように見えるのも気になる。 もっと広くStrictな話が出来るといいなと自分は思うんだけどね。
>>46 構造を利用するのが表示だけとは限らない。
そこってXMLで語るかHTMLで語るかで大分変わってくるような気がするんだが、どうだろう。
>>48 目的がなんだろうとわかりようが無いのは人間だけじゃね?
>>50 その構造が本当に必要なものかどうかを判断するのは難しいな
不必要なものまでむやみにマークアップするだけなら、div多用と大差ないし
>>48 日本語でおk
>>43 さらに自己訂正
> そして、「こういうデザインにはこれだけの論理構造が必要」という
> 方針で論理構造を考える、とこのスレで発言するのは、問題の
そして、「こういうデザインにはこういうマークアップが必要」という
方針でマークアップを考える、とこのスレで発言するのは、問題の
訂正に2レス費やすとか死ねよ
>>49 >43の
> なぜなら、デザイン云々はスレ違いで、必要とされる論理構造が
> どの程度か、というところまでしかこのスレの範疇には含まれない
> からだ。
というのは俺が間違ってた。おまけに、そもそもそこは問題じゃなかった。
>>53 > その構造が本当に必要なものかどうかを判断するのは難しいな
冗長とかそういうのはStrict仕様上の問題じゃないだろうな。
Strict精神というのも違うだろうし、強いて言えば保守性の問題
じゃないかな。
ソース上での改行は適宜しましょう、とか、インデントはすべきか、
とか、そっちの問題な気がする。
そして保守性を求めて多重DIVだらけに・・・
多重divだらけにしなくても、保守性は保てるけどな。
つーかそれよくないだろ保守性
>>50 >>20 の下から5行くらいを読んでもらえるとありがたい。
自分が見て分かるためって言う利用法もあるかもしれないけど、
そう言うことなら
>>55 の言うとおりだと思う。
>>54 その訂正を見て
>>21 が何を言いたかったのか分かった気がする。
論理構造をHTMLで表現することをマークアップと言ったつもりなんだけど
このスレでは、あまり妥当な言葉じゃないのかな。
>>56 「過剰はマークアップは保守性がよろしくない」
というのを想定して55を書いたんだが。
>59
> その訂正を見て
>>21 が何を言いたかったのか分かった気がする。
訂正した俺は、21が何を言いたいのか分からない。
2軒隣の家が火事なのだが、俺は逃げたほうがいいのか?
firewall(一軒隣の家)があるから大丈夫だよ。
64 :
Name_Not_Found :2006/08/08(火) 09:39:25 ID:sji1ILIx
【心の】旦那には絶対言えない過去【奥に】
http://human5.2ch.net/test/read.cgi/ms/1154259322/ ・新婚早々、同居していた高校生の義弟に体を許してしまったことです
・大学生の時に、バイト先の社長と定期で会ってたこと。ピル服用、週2回の条件で月10万円は魅力でした
・旦那(当時彼氏)と交際中、4マタかけて、どの人と結婚しようか選んでいた
・長女の血液型、A型になってるんだけど実はABだってこと
・レディースだったこと。子供三回堕してること
・学生時代にシャブ中だった事。
親からの仕送りも、殆ど覚醒剤に消え、風俗嬢と愛人やりながら、薬にドップリ溺れ逮捕された事は、旦那には絶対に絶対に言えない
・援、風呂、整形、堕胎。言ってない
・経験人数三人はうそ10人越えてます
・まだいいじゃん。私何人かわからんわ
・援 風 整形 過去の犯罪歴 隠して結婚してます。
・中学の頃円光・整形・家出・乱交やりまくり・
風俗・家庭内暴力・過食嘔吐・薬首吊りリスカの自殺未遂でicuに入った事
【調査】 女性、結婚焦るのは"30歳"から&あきらめは"40歳"…33歳超えると「恋人なし」過半数★9
http://news19.2ch.net/test/read.cgi/newsplus/1154945288/ 【番外編】・もし処女が良いと言っている男性諸君がいるなら敢えて告げて置こう
今は若い女性の方が処女率は低いと言う事だ
それは10代ぐらいの時から少女雑誌にそういう特集が書いてあって
処女だとカッコ悪いとかそういう者に躍らされて早く捨ててしまうからだ
・ネットでコソコソと30女がババアとか煽ってるのなんて可愛いほうだと思う
最近の小学生は20歳の子のことをババア呼ばわりして馬鹿にしてるし
20歳前後の女の子たちは25歳過ぎの人をババアキモイ呼ばわりして平気だしね
中学1年くらいで初体験済ますくらいだから、本当にすごいよ
ババア生理あがってんだろ!みたいなことをガキに言われたときは凹んだけどね
<h1>h1</h1> <p>p</p> <h2>h2-1</h2> <p>p</p> <h3>h3-1</h3> <p>p</p> <h3>h3-2</h3> <p>p</p> <h2>h2-2</h2> <p>p</p> <h3>h3-3</h3> <p>p</p> <h3>h3-4</h3> <p>p</p> これをdivでまとめるとしたらどうしますか?
67 :
66 :2006/08/08(火) 10:23:53 ID:???
こう?「例1」 <div class="h1"> <h1>h1</h1> <p>p</p> <div class="h2"> <h2>h2-1</h2> <p>p</p> <div class="h3"> <h3>h3-1</h3> <p>p</p> </div> <div class="h3"> <h3>h3-2</h3> <p>p</p> </div> </div> <div class="h2"> <h2>h2-2</h2> <p>p</p> </div> <div class="h3"> <h3>h3-3</h3> <p>p</p> </div> <div class="h3"> <h3>h3-4</h3> <p>p</p> </div> </div> </div>
こう?「例2」 <div class="h1"> <h1>h1</h1> <p>p</p> </div> <div class="h2"> <h2>h2-1</h2> <p>p</p> </div> <div class="h3"> <h3>h3-1</h3> <p>p</p> </div> <div class="h3"> <h3>h3-2</h3> <p>p</p> </div> <div class="h2"> <h2>h2-2</h2> <p>p</p> </div> <div class="h3"> <h3>h3-3</h3> <p>p</p> </div> <div class="h3"> <h3>h3-4</h3> <p>p</p> </div>
69 :
66 :2006/08/08(火) 10:26:04 ID:???
またそれぞれhはdivの外に出すべきですか? 「例1」の各hをdivの外に出したものを「例3」 「例2」の各hをdivの外に出したものを「例4」 として 今後のことも考えてどれがいいか教えてください。
>>69 >>67 と
>>68 は全然意味が違うだろうが。
それすら*自分でさえ*わからないような文章を書いてる奴は何やっても無理。
色見本のテーブルを用意している・・・・んだが、 画像なんか作らずにfont要素使った方が健全な気がしてきた罠。
わかりやすく:仕様だから
Level2のhも個別にsectionで括るか Level3のhを個別じゃなくてまとめてsectionに括るかするのは仕様外ってこと? リンク先の方法だけ? それとも Level2のhも個別にsectionで括るか Level3のhを個別じゃなくてまとめてsectionに括るかするのも問題なし? 日本語でわかりやすく解説してください。
ていうかマジで言ってるんだとしたらどういう目をしてるんだよ。 もう100階リンク先を見て恋。
まあ2.0が変なのは昔から言われてきたことで
しかし久し振りに2.0を見たら、acronym element残ってたんだな。驚いた。
>>75 本気で言ってますすみません。
リンク先のどのかしょを100階見ればいいでしょうか。
例だとsectionでの構造化が統一されていないように見えます。
最悪はnl要素だと思うんだが、どうよ。
>>80 同意。>最悪
>for ordered presentation.
なんて書かれているし……。
>>79 なんでわざわざ例として統一されてないのか考えてみよう。
仕様だからですか?わかりません><
もう100階リンク先を見て、仕様だということがわかりました。
↑ていうかマジで言ってるんだとしたらどういう目をしてるんだよ。
どこまで本人かわからんが、ワロス
要は、 <section> <h>見出し</h> <p>段落</p> </section> という書き方も出来るし、 <h>見出し</h> <section> <p>段落</p> </section> という書き方も出来るという仕様なのでは。 ISO-HTMLよりもあいまいな構造ですね。
ISO-HTML最強!って流れ?
見出しがセクションの外にあるのに 全ての見出しレベルのセクションが同じ名前ってのが気に食わない。 セクション内に見出しを入れることしかできないか、 セクションの外に見出しを出すのなら「h1に対応する名前はdiv1」というように 関連付けられていることを明示的にしてほしい。 またはlabel要素のようにfor属性で関連付けるとか。
>>89 見出しレベルがなくなるんだからそれはナンセンス
>>87 その二つだとレベルが変わるということは分かるな?
>見出しがセクションの外にあるのに え?
>>72 のリンク先はそういうことじゃないの?body直下のhとsectionがセットじゃないの?
sectionとその中のhがセットだけど一番最初のhだけはセットとなるsectionがなく
body直下に現れる、ってこと?
>>93 セットという概念はない。
sectionをかますとhのレベルが1つ落ちるだけのこと。
だから1つのsectionに複数hも認められているし、sectionとhを1対1にしてもいい。
しかし
>>87 の下はhがないから無駄。
明示的がどうのこうのってのはdt・ddを使うときに思うわ。
dtの始まりからddの終わりまでで明確なんでないの。
一つのdtに対しddがいくらあってもいいし一つのddに対しdtもいくらあってもいいからなあ。 それでいてdlの中にさまざまな対のdtとddを入れられるし。
だから「dtの始まりからddの終わりまで」なんだろ?
まあデザイン上は複数ddや複数dtの場合は纏めたいってのはわからないでもないが、 構造上は明示的だと思うけどなあ。
無駄に <dl> <dt>1</dt><dd>1'</dd> </dl> <dl> <dt>2</dt><dd>2'</dd> </dl> としているけど許して。 さらに各dlごとにul,liやol,liの中に入れてたりするけど許して。
しかし許さん!
今盛り上がってる?
普段どおりだよ。悩みがあるなら話して見なさい。
もてないんです・・・
えっと、
ttp://www-06.ibm.com/jp/accessibility/guideline/skip.html#main ここに例として
> <a href="#navskip">ナビゲーションリンクをスキップ</a>
> ...
> <a name="navskip"></a><h1> 本文...</h1>
とあったのですが
各ページ共通のサイト名やメニュー・ナビゲーション類には
h1とかh2とか付けるのはよくないんですか?
付けるべきじゃないんですか?
今までは
<h1>サイトのタイトル</h1>
<h2>ナビゲーション</h2>
<!-- ここにメニューやら -->
<h2>記事のタイトル</h2>
<!-- ここに本文 -->
ってやっていたのですが、言われてみれば
ナビゲーション類を章に含めるのはおかしいかな、と思い始めて。
そういえばサイトのタイトルにh1要素は使わず
title要素をスタイルシートで表示させているサイトを以前見かけたような気がします。
IEには対応していなかったような気もします。
そのとおり ナビゲーションもlink要素があるからわざわざ別に作る必要はない むしろ作ってはいけない 対応していないUAは無視しなさい
>>107 h1の配下に置くんだったら、h2つきでいいと思う。
ローカルナビゲーションだったら、そこに置かざるを得ないと思うし。
そこのリンク先の例は、グロバールナビゲーションだからh1外に追い出してる例。
グローバルナビゲーションは、確かに文書外だからlinkをJSで書き出すのがStrict的に最も美しいかもしれないけど、
まあ文書内に書くとしたらh1外しかないかな、ということで、結果としてその場所になり、
グローバルなもの何度も読ませるのは悪いから、ということでスキップが入ってる。
タイトルは、むしろtitle=h1であるべきと思うけど。
いやしかしそんな小さな文字でアクセシビリティか・・・・・・IBM・・・
というよりXHTMLでテーブルレイアウトですぜ
>>109 こういうことですか?
<html>
<head>
<title>章の題名</title>
</head>
<body>
<div><!-- グローバルナビゲーションやサイト内検索フォームなど --></div>
<h1>章の題名</h1>
<p>文章本文</p>
<h2>項の題名</h2>
<!-- 以下文章が続く -->
</body>
</html>
>>112 の場合にサイト名はどうマークアップするの?
今はh1にサイト名、h2にそのページのドキュメント名、
そしてtitleにはh1+h2にしてるけど。
h1より前にいろいろとあると気になってしまうけど、そこは問題ない?
<a name="navskip"></a> ↑これはどうなの。
それすごく気になった。 <h1><a name="navskip">本文...</a></h1>
>>112 割といいと思う。
Strictじゃなくてユーザビリティを考えるなら、
titleだけは「サイト名-章の題名」みたいな人も多いらしいけど。
>>113 サイト名は普通トップだけじゃね。
h1にサイト名は邪道というのはよく見かける。サイト名も「文書外」だろうし。
h1の前に*その文書外の*グローバルナビがあるのはおかしくないと思う。
共通のフッタ部分は112の例で言うと</body>直前にグローバルナビと同様に<div>などで配置ですか?
idジャンプに対応していないUAとかなかった? 実装に関する話題は対象外だっけここ
フッタってfooterで足下のどこが構造よと思う。 結論:フッタイラネ
>>119 対象外だが、一応。対応してないのはNN4以下とIE3以下だと思った。
122 :
114 :2006/08/08(火) 20:58:13 ID:???
>>117 うん、
<h1 id="navskip">はげほげ</h1>
h1に"navskip"というidが付くのは気持ち悪いから、
<h1 id="toplevel-heading">はげほげ</h1>などとして
<a href="#toplevel-heading">ナビゲーションリンクをスキップ</a>
てのが妥当かと思ったけど、
どの音声ブラウザもちゃんとidで飛べるのか気になった。
toplevel-headingはh1と意味的に同じだからちょっと気持ち悪い、かな。 最近の音声ブラウザは飛べるようだけど、古いのは知らない。すまん。
あ、だからって「navskip」はもっと気持ち悪いんだけどね。
わかりやすいfooterがないとファイルを正常に読み込めていないんじゃないかと思ってしまう ナローバンドな俺。
>>122 ちょっと見たら、IDで飛べなくても、見出し毎に飛べたりするらしい。
・・・・ビジュアルブラウザにもホスィ。
見出しからツリー構造を判断してサイドバーにツリーを表示してくれるタブブラウザがあったような。
>>125 ナローだから軽いCSSだけ当てて「わかりやすいfooter」なんかがない俺。
レンダリングをさせないだけで効果があるの?多重入れ子tableとかも問題なし?
>>130 そういう意味じゃないw
フッタはビジュアル的に本文と分けられてることが多いけど
そんな装飾を取っ払ってあるからパッと見見分けがつかなくて「わかりやくない」というだけ。
ああ、意味がわかりました。見かけ上は本文とシームレスになってるのね。
>>112 これ「グローバルナビゲーションやサイト内検索フォームなど」には見出しはなし?
dl,dt,ddを使うとか?
<a href="#hoge">ほげ</a>って画面がスクロールするだけ?フォーカスは移動しないの? 各UAにゆだねられてるの?
なんでこんな質問厨が湧いてるんだ?
知らない人はレスしないで!
>>95 結局の所、section要素は、見出しによるセクション構造などは提供しない
のであって、単に「『その要素内のh要素のレベルを下げる』という意味が
追加されただけのdiv要素」という程度の要素なんだな。
つまり、h1〜h6とdivを使っているのと意味的には変わりないと。
>見出しによるセクション構造などは提供しない そうでもない。見出しと一緒でないと使えないことは確かだから。 ただし今のセクションdivのように個別対応というわけでもないというだけ。 ただ気になるのは、blockquote内のhだよな・・・・ 見出しレベル下げるためにsection入れなきゃならないだろうが、 どこにどう入れることになるのやら。
漫画の台詞の引用なんだが、改行まで必要な場合(改行位置の比較をやってる) どう考えても段落じゃない改行はやっぱりbrを使うしかないんだろうか。 それともspan?どっちにしろスマートじゃなくて迷ってるんだが。
改行そのものに意味があるんならbr。 spanなんぞ使ってどうすんの?CSSでdisplay:blockとするんだろうが、 CSS使えない閲覧環境で意味が変わっちゃうだろ。ダメダメだ。
その場合は、<br>が「スマート」じゃね?
<blockquote> <pre> ナッパ!!!!! オレのいうことがきけんのかーーーっ!!!!! </pre> </blockquote>
前スレ
>>947 の話題をひっぱるかたちになるけど、
<h1>第一章</h1>
<h2>第一節</h2>
(第一節の内容)
<h2>第二節</h2>
(第二節の内容)
[ 次の章へのリンク ]
こういう時はやっぱり、
[ 次の章へのリンク ]にも見出しを付けるべきなのかね。
(その場合見出し語は「ナビゲーション」か?)
なんかすごく気持ち悪い気がする。
<div id="honbun-toha-kankei-naiyo" title="本文とは関係ないよ"> [ 次の章へのリンク ] </div>
>>147 それは…。
でもそういう意味を持った要素がもともと用意されていたらよかったなと最近思う。
>>146 どのブラウザもlink要素でのナビゲーションに対応してればいいんだけどねえ。
>>149 それも考えたんだけど、下まで読ませといて、上まで戻らせるのはどうなんだろうと。
ユーザビリティに言及するのはスレ違いになるのか?
とりあえず本文の最後に[ 次の章へのリンク ]を入れるという前提で、
何かいい方法は無いものだろうか。
>>150 いやだから、見出しが持ち悪いと考えるから、そうなるんじゃ?
俺だったら気持ち悪いと思わないから、素直に見出し入れて下にする。
あと >でもそういう意味を持った要素がもともと用意されていたらよかった これは単にレベルの問題だから、どんなのでも無理。
>>151 うーん、気持ち悪いと思うのは俺だけなんだろうか…。
仮にこれが論文だとしたら、論文の中身とは関係の無いものが、
論文の見出しと同じレベルで置かれているというのが何ともね…。
それがHTMLだといわれればそれまでなんだけど。
>>152 それはただの「〜だったらなあ」という儚い希望的空想なので
深く突っ込まないでw
第一章 うんこは本当に茶色いか 1. 2. 3. 次の章へ
>>153 だったらISOじゃないんなら、別に全てフラットになるから
>>146 のだけでいい。
但しh2も構造上はh1配下ではないことになるが、
元々人間の脳はそんな構造化されてる訳でもないから、勝手にh2がh1配下だと思ってくれる。
ストリクタがbrを使う時ってどんな時?
ちょっと上のレスも見えないのか?
改行だけ整形済みの場合か
>>150 >どのブラウザもlink要素でのナビゲーションに対応してればいいんだけどねえ。
>>1 >実装の話は10中8, 9スレ違い。
対応してないブラウザ?知るか。正しさには関係ない。
a要素によるISBNコードを用いたリンクについてどう思いますか? 自分としては「間違いでは無い」と思っているのですが、 現時点では対応しているブラウザが皆無なことから、どうもやるのを尻込みしてしまいます。
今対応してなくてもそのうち対応するだろう事をやっておいても損はなくね? link要素だって対応してるUAがなくたってやっておいて損がないようにさ。
アマゾンとかにリンクすると「書籍の販売ページへの参照」になってしまうのが駄目。 HTMLは暗示された意味を明示するためのものだと思っているから、アマゾンとかへのリンクを張ることで「その本を売りたい」気持ちが入ってしまう機がする。 かといってurn:isbnも面倒だし、書籍名で検索すれば関連ページはすぐ出てくるので、俺はリンクアンカーを張らないことにしている。
>urn:isbnも面倒だし この精神は駄目
>書籍名で検索すれば関連ページはすぐ出てくる お前のサイトはアマゾンかGoogleに依存しないといけないの?
実用性を考えるならやっぱりアマゾンとかへのリンクかな。 売りたい気持ちがって言うのもわかるけど 現状最も実用的な書籍データベースは、オンラインショップなのも事実かと。 JavaScriptでもいいなら、urn:isbnからアマゾンへのリンクを生成するという手もある。
>>164 俺は「マークアップできるところは必ずマークアップしなければいけない」とは思わない。
>>165 その書籍のisbnをすべての人が知りたいわけではない。「書籍名だけは記しておきますから、この書籍の情報を知りたい人は好きに調べてください」という考え。
isbnを明示したところで、その書籍の情報を知りたい人は、書籍名やisbnで検索するしかない。まさかisbnだけを知りたい人なんて早々いないだろう。
>>167 とりあえずマークアップの前に改行を覚えてくれ。
>>167 「利用者が知りたいから」という観点で語るんだったらスレ違い
strict精神を現実のwebにおいてどう実現するかを語るのは スレ違いじゃないと思うがな。
171 :
170 :2006/08/09(水) 23:11:18 ID:???
>>167 読みづらいだけだったらUserCSSでも使ってくれ
>>168 俺は
>>30 なんだけど、
>>30 で書いたように「利用者が幸せになれないマークアップは無意味」だと思っている。
isbnが明示されていて不便になることはないはずだけれど、あまり便利にならないようならマークアップしなくてもよいと思う。
話がずれていたら御免。
専ブラを知らんのか
>>170 Structの精神から派生してその結論に至ったわけじゃなく、
利用者が知りたい事から敷衍してその結論に至っているようにしか見えないんだが?
175 :
170 :2006/08/09(水) 23:23:32 ID:???
>>174 確かに、
>>30 の「Strict→幸せ」が正しいとしても、「幸せ→Strict」とは限らないね。申し訳ない。
それで疑問なんだが、「Strictの精神から派生した結論」ってどんなものが考えられる?
>>177 正直どこがどれにレスしてどう繋がってるのかわからないがorz
例えば
>>141 のような場合、所謂「改行すると幸せだから楽だから」brを使うのではなく、
brという改行の意味を考えた結果のような気がするんだが、どうだろう。
思ったんだが、brを使わない為にpreって本末転倒じゃないか?
使わないためにpreと答えた訳ではないと思うが、どうなんだろう
181 :
Name_Not_Found :2006/08/10(木) 13:01:08 ID:SDN3A2Iy
XHTML 2.0でsection要素ってありますよね <h>Events</h> <section> <h>Introduction</h> <p>....</p> <h>Specifying events</h> <p>...</p> <section> <h>Attaching events to the handler</h> <p>...</p> </section> <section> <h>Attaching events to the listener</h> <p>...</p> </section> <section> <h>Specifying the binding elsewhere</h> <p>...</p> </section> </section>
↑と↓の違いがわからん <h>Events</h> <section> <h>Introduction</h> <p>....</p> <h>Specifying events</h> <p>...</p> <section> <h>Attaching events to the handler</h> <p>...</p> <h>Attaching events to the listener</h> <p>...</p> <h>Specifying the binding elsewhere</h> <p>...</p> </section> </section>
なんで一番深い階層にあるh要素とp要素だけ、一組づつ括ってるの?
本当に上の方を100階読んで恋。
>>95 を見るかぎりだと、
・どちらでもよい
・
>>181 の方がまとまりを明示しているだけ
ってことでおーけーです?
>>95 に対するレスがないもんで、過去ログ読んでて他に何かあるのかな、と。
途中で送信してしまった orz それと、address要素については下のような構造という認識で問題ないでしょうか? <h>Events</h> <section> <h>Introduction</h> <p>....</p> <section> (省略) </section> </section> <address>連絡先</address>
>>187 それだとaddress要素がトップレベルの見出しの中身にならないか?
<div id="honbun-toha-kankei-naiyo" title="本文とは関係ないよ"> <address>連絡先</address> </div>
複数の記者がいるサイトなら各記事ごとのセクション内にaddress要素を入れればいい。
191 :
186 :2006/08/10(木) 13:35:49 ID:???
・・・・・
まとめると、
・
>>181 と
>>182 のどちらでもよい
・
>>181 の方が構造を明示しているだけ
・adderss要素などの置き場所はXHTML 2.0においてもない
ということでFAですか
あるいは、
<h>Events</h>
<section>
<h>Introduction</h>
<p>....</p>
(省略)
</section>
<section>
<h>連絡先</h>
<address>うんたらかんたら</address>
</section>
とか??うーん…
あ、
>>190 さんとかぶってしまった orz
なるほどです。
一人の著者しかいない場合は >> 191みたいな感じしかないのでしょうかね
XHTML 2.0も結構曖昧ですね…
私だったら次のようにマークを付ける。 <h>Events</h> <section> <h>Introduction</h> <p>....</p> </section> <section> <h>Specifying events</h> <p>...</p> <section> <h>Attaching events to the handler</h> <p>...</p> </section> <section> <h>Attaching events to the listener</h> <p>...</p> </section> <section> <h>Specifying the binding elsewhere</h> <p>...</p> </section> </section> hから次の同レベルのhの直前までが1つのsection(節)と考えるのが自然だと思う。
>>180 思い返してみると、使いたくないからpreって場合ばっかりだった気もする
>>193 それは違う気がする
トップレベルは下層を包括する、というのがsection要素なんじゃ?
>>193 そうすると、それらを更に一つのsectionで囲む必要があるな。
>>181 バージョンと同様に2階層目も構造を明示した、ってことね
結局、section要素ってわけわからんな
どういうのがいいんだ?
>>193 で全部囲むとなると >> 181 はおかしいことになるよなあ…
>>197 さらに囲む必要はないでしょ
囲んだら2階層目が抜ける
>>181 をさらに構造化したのが
>>193 のってことでしょう
で、じゃあその場合、address要素はどこに入るのかなあ?
<h>1</h>
<section>
<h>2-1</h>
<p>....</p>
</section>
<section>
<h>2-2</h>
<p>...</p>
<section>
<h>2-2-1</h>
<p>...</p>
</section>
<section>
<h>2-2-2</h>
<p>...</p>
</section>
</section>
<address>
[email protected] </section>
こんな感じ?
>>194 その発言はpreの力を軽んじている証拠!preを軽く見るな!preはすごいんだぞ!
だからなんでaddressを最後に持ってきたがるの
<address>
[email protected] </section>
<h>1</h>
<section>
<h>2-1</h>
<p>....</p>
</section>
<section>
<h>2-2</h>
<p>...</p>
<section>
<h>2-2-1</h>
<p>...</p>
</section>
<section>
<h>2-2-2</h>
<p>...</p>
</section>
</section>
これで解決。
204 :
203 :2006/08/10(木) 16:05:13 ID:???
サイト全体のグローバル情報としてのaddressはlink要素で、 そのページの連絡先ということだったらh1配下が正しいような気がするんだが。
そうだね。addressをどういう意味合いで使いたいのかも言わないで addressの位置はここでいいですか、とか言われても。
いや、位置というよりは構造についてどうするのがいいのか? って感じ 基本的に著者の情報(1人)を書くとして、 h1に当たる要素とそのsection要素と同レベルでいいのかな?
だから、その構造が意味合いによって変わってくるだろっつー。 各章毎にaddressを必要とする人もいるんだし。
いや、ありなのかどうかってことです あり、っぽいですね で、前にも出てますが、ナビゲーションとかいうのは、 <dl> <dt>ナビげーション</dt> <dd>ナビ1</dd> <dd>ナビ2</dd> <dd>ナビ3</dd> </dl> <h>見出し1</h> <section> <h>見出し2</h> <p>・・・</p> </section> みたいになるのかあ。なんか気持ち悪いな・・
何そのナビゲーション?意味がわかんないんだけどぉ? 前に出てるならレス番を引用しなさいよ
・・・・・・上にも出てたが「どういう目をしてるんだろう」というのは確かにいるな・・・
>>112 とかだけど?
dlだとかをhの上にやるしかないでしょ
>>212 何か言う前にXHTML2.0のナビゲーションを調べてこい、な?
上にもヒントは出てるから。
いや、そりゃあhead要素の中で示すのはわかるけど それとは違う話をしているわけで… 現実にはこういうナビゲーションとかメニュー的なもんが必要になるでしょう それをどうするのがよいのかなと思ってね
>>214 何か言う前にXHTML2.0のナビゲーションを調べてこい、な?
nl要素のことかw スマソ いや、実はXHTML 1.0、1.1で2.0のような構造を実現しようとしてたんだ となると現状ではやっぱりdlとかulとかでやるのも間違いじゃないみたいだね
dlでやってる香具師は見たことない
スマン じゃあ、 <ul> <label>ナビゲーション</label> <li>ナビ1</li> <li>ナビ1</li> <li>ナビ1</li> <li>ナビ1</li> </ul> とか?dl要素の方がよさそうなんだが・・
ナビゲーションをそんな一般的じゃない定義リストで書かれたら意味がわからんじょー 俺はマークアップするならul/liだす <ul> <li>第一章 <ul> <li>第一節</li> <li>第二節</li> <li>第三節</li> </ul> </li> <li>第二章 <ul> <li>第一節</li> <li>第二節</li> <li>第三節</li> </ul> </li> <li>第三章 <ul> <li>第一節</li> <li>第二節</li> <li>第三節</li> </ul> </li> </ul> これならツリー構造で親子関係兄弟関係がわかる。縦のつながり横のつながりがわかる。
>>219 ・・・・・・・・・・・・・・・・・・・・・・・・・・。
<!ELEMENT UL - - (LI)+ -- unordered list -->
222 :
220 :2006/08/10(木) 17:15:26 ID:???
contents(ToC/Table of Contents)ページに書くような内容だと思う。
224 :
220 :2006/08/10(木) 17:17:15 ID:???
>>223 索引(index)じゃなくて目次(contents/ToC/Table of Contents)じゃない?
Link要素のrel属性の値で言うところの。
>>220 なるほど、ありがとうです m(__)m
たしかにdlだとdtとddのつながりと構造が希薄な気がする・・・
なかなか奥が深いのう
繋がりと構造以前の問題だろ219は
索引なら
>>220 みたいなのがよさそうですね。
>>224 そうです、どっちかというとToCの方はどうするのかなと
nl要素の例を見ると、Tocなら
>>219 みたいな感じかdl要素でもいいのかな
219は不思議マークアッパー。日々不思議を追求しています。
あ、スマン
>>219 だめじゃん、ulの子要素になれるわけねええっっw
じゃ、やっぱdlか
なんでToCでdlになると思うんだか、その思考回路が計り知れん。
索引(index)というのは > あ行 > あご勇(-いさむ) … 20ページ > 赤穂義士(あこうぎし)⇒赤穂浪士 … 21ページ > 吾郷清彦(あごうきよひこ) … 24ページ といったものが書かれているページだと思うけど。書籍でいうと。 マークアップは同じようになるだろうけど。 dl、dt、ddを使うのは用語集(glossary)ページじゃない? > あ行 - あこ > あご勇(-いさむ) > あご勇(あご いさむ、1957年8月14日 - )は、千葉県出身の日本の俳優。本名は… > 赤穂義士(あこうぎし)⇒赤穂浪士 > 赤穂浪士(あこうろうし)とは元禄15年… > 吾郷清彦(あごうきよひこ) > 吾郷 清彦 (あごう きよひこ, 1909年 - 2003年6月5日) は、超古代史研究家。… こういうページ。dl、dt、ddがよく似合う。
>>230 それが不思議で聞いてみたんだよね
最初に言わなかったのが悪かったですが、XHTML 1.0、1.1での話です
nl要素の例:
<nl xml:base="
http://xformsinstitute.com/essentials/browse/ ">
<label>Table of Contents</label>
<li href="ch01.php">Introduction to Web Forms</li>
</nl>
これの構造をXHTML 1.0とかでやろうとすると、dl以外にない気がするけど・・・
それともこんな感じ?
<dl>
<dt><label for="TOC">TOC</label></dt>
<dd id="TOC">
<ul>
<li>content1</li>
<li>content2</li>
</ul>
</dl>
どんどん混乱していくっw
> マークアップは同じように
ってのは
>>220 と同じようなul、liを使ったツリー構造って意味です。
キャプションを付けたがるなっ! 目次専用、索引専用、用語集専用のページを作って <body> <h>目次</h> <ul> … </ul> </body> でいいじゃなーい?
>>231 だとすると
<dl>
<dt>TOC</dt>
<dd>content1</dd>
<dd>content2</dd>
</dl>
とか
<dl>
<dt><label for="TOC">TOC</label></dt>
<dd id="TOC">
<ul>
<li>content1</li>
<li>content2</li>
</ul>
</dd>
</dl>
とかでいいと思うんだけど?
俺がおかしいのか?(汗
>>231 >こういうページ。dl、dt、ddがよく似合う。
まあ、もともとそういうものの為の要素だし。
>>234 それをいっちゃあ・・・それこそJSでやれみたいになっちゃう・・・
TOCもそうだけど、サイト全体を通してのメニュー的なものをいれようとしたら、
>>235 みたいしかないと思う
ローカルナビならhn要素の下に入れればいいんだろうけど・・・
>>235 目次は項目の羅列だけでいいじゃない。
<li><a href="項目のある場所">項目名</a></li>
これを階層化し羅列するだけでいいじゃない。
目次には目次専用のページがあって、このページは目次です!って書きたかったら
>>234 でいいじゃなーい?
同じページ内に無理やり入れたいのなら
<ul title="table of contents">
中略
</ul>
<h><!-- ここから本題だよ --></h>
でいいじゃなーい?
ul > table君にだけcaptionがついててずるいー table > ごめんよー って話?
>>238 トンクス
いやあ、こうやって考えるとマークアップも難しいな・・・
<ul id="TOC">
<li>目次(またはメニュー)</li>
</ul>
<h1>見出し1</h1>
<div class="section">
<h2>見出し2</h2>
<p>・・・・・</p>
<h2>見出し2</h2>
<p>・・・・・</p>
<div class="section">
<h3>見出し2</h3>
<p>・・・・・</p>
</div>
</div>
最終的には再現しようとするとこんな感じになるのか キメェw
キモさを乗り越えたその向こう側に快感が待っている。 人はそれをストリクターズ・ハイと呼ぶ。
呼びません
Strictスレは勉強になるなぁ
少し上のほうにcontentsやindexやglossaryが出てますが <link rel="" />ってのはどれだけ書いていますか? startとalternateとstylesheetとalternate stylesheet(とshortcut icon)だけしか使ってないんですが contentsやらindexやらglossaryやらappendixやらhelpやらbookmarkやら chapterやらsectionやらsubsectionやらを使っていますか? あ、contentsはサイトマップのページに使ってました。
copyrightとhelpも使いやすいんじゃね?
profileの定義はどうしてる? 無視?
alternate stylesheetって・・・ 意味はalternateとstylesheetをスペース区切りで併記してるだけじゃん。 ・・・って、じゃあshortcut iconはshortcutとiconの併記になるのか?おしえてMS!
glossaryやらappendixやらhelpやらbookmarkやら そもそも該当するページがないwww から使わない。 prevやnext、contentsなんかは当然使う。
bookmarkの意味がいまいちわかりません。 いわゆる「リンク集」みたいなページとは違うってことはわかったんだけど。 サイトによって「しおり」ってだけ説明してあったり。
ねすけを知らない世代かしらん
「お気に入り」のこと? それを一般に公開したものがいわゆる「リンク集」って呼ばれているやつじゃないの?
しおりもブックマークも同じ意味だよ。お気に入りは若干違うけど。 その文書に関連するページを明示する。 だからページ毎に別々のブックマークを付けられる。 所謂ごった煮のサイト全体のブックマークページとは別。
>>250 この場合、ネスケは関係ない
>>249 ページ内の特定の箇所へのリンクを明示するためのもの
要するにページ内リンクを link 要素を使って実現するといっていいだろう。
page_a.htmlからそれに関するpage_b.htmlの特定の箇所(#hogeなど?)を書くってことですか? 「この章に関しては第何章の何項(の何行目)を参照」って意味合い?
仕様書には以下のように書いてある。 >ブックマークとは、長い文書の中の、ある重要な入り口に対して設定されたリンクである。 >例えばブックマークのラベルなどとして、title属性が使われることがある。 >1つの文書に複数のブックマークを設定できる点に注意されたい。 例をあげるなら、以下のような感じ。 <link rel="bookmark" title="第1章" href="#chapter-1" /> <link rel="bookmark" title="第2章" href="#chapter-2" /> <link rel="bookmark" title="第3章" href="#chapter-3" /> 外部のページに使ってはならないということはないと思うが、 基本的に同一ページで使うものだと俺は理解している。
本の重要なページにポストイットで印付けとくじゃん、あれだよ。 特定の箇所というのは必ずしもfragment識別子(#hogeとか)が付くとは限らない。 大きな文章が複数のhtmlから成っていれば、その1つのhtmlをfragment識別子無しで指しているようなものも考えられる。。
ということは実装を考慮に入れなければ ■バナナ(章) ・バナナについて ・バナナの利用法 ・バナナを育てよう □バナナについて(節) バナナとは。。 の章の直下のページ内リンクも不要ってことですか?
ポストイットを付けるのは読者であって著者ではないんだが…
257は255に剥けてです。
>>255 ちょい待ち、そういう奴はchapterだろ。
start next prev contents index glossary copyright chapter section subsection appendix help bookmark のうち next prev chapter section subsection bookmark がページごとに異なり それ以外は全ページ共通なんですか?
bookmarkの認識がみんなばらばらで、ほっとしていいのかどうなのか。
いや、上のも共通じゃない。 無論共通にできる構成のサイトもあるだろうが。
>>260 rel="chapter" の場合は、複数の文章から構成されている場合に用いる。
>文書群の中の章である文書を指す。
と、仕様書にもある。
単一の文章の特定の箇所を示すには、bookmark でしょう。
しかし、まぁ誤解を招きやすい例だったかもしれない。
ということで、ありがちな例をもうひとつ。
<link rel="bookmark" title="本文" href="#main" />
>>264 言葉の定義そのものが違いそうだ。
文書群って、別にページが分かれてる分かれてないは関係ないぞ?
ああ、もしかして
>>264 は
>ブックマークとは、長い文書の中の、ある重要な入り口に対して設定されたリンクである。
これも一ページ内の長い文書限定と考えてるのかな。
俺は文書「全体」として考えてるんだけど。
>>265 まぁね。そこらへんははっきり書いてないので解釈の違いがあるかもしれない。
しかし原文では、documents となっており、普通に解釈すれば別ページと解釈するのが妥当だろう
ちなみに start や next なんかも、documents = 文書群 となっているが、
これを単一ページで使う例は見たことがない。
ブックマークは全体へのみってのはおかしくない? 特定の一部分への場合もあって当然だし、両方あるのが当たり前だと思うんだけど。
>>264 いや、「1文書」で12345と章があったとして、それをページで分けるかどうかは任意だろう?
それを1ページだったらブックマーク、5ページだったらchapterになるのは整合性がないと思うんだ。
だから文書群=documentsは、1〜5で複数形という意味で。
>>264 多分全体というのが解釈違いだと思う。サイト全体じゃないよ。
「一連の関連ある1文書」という意味での全体。
だから当然ページによってブックマークが変わるのはあり得ると思ってる。
また、「一連の1文書」全体であっても、当然その章のみに関連するページもあって然るべきだと思うし。
<link rel="bookmark" href="diary.html" title="日記"/> <link rel="bookmark" href="bbs.cgi" title="掲示板"/> <link rel="bookmark" href="link.html" title="リンク"/> って、使い方もありだろうか。 サイトという一連の文書の中の重要な入口ってことで。
咀嚼してください・・・
>>269 >それを1ページだったらブックマーク、5ページだったらchapterになるのは整合性がないと思うんだ
整合性がないことはないだろう。そのために bookmark と chapter がそれぞれ用意されているわけだし。
単一のページでも documents であるとするほうが整合性がないと思うが。
>>173 >そのために
ごめん、ここ繋がらない。
>単一のページでも documents
だからそれは本当に解釈違い。
documentは「一塊の文書=章/節/全体」どれでもイケると思ってるから。
そもそも、ページの違いってのはどの程度の差がある目安なんだろ 1章と2章が同じページにあってもいいし、別のページにも分かれててもいい状態では、 単なる製作者の意図と、転送量やサイズ、見易さを考慮して決められただけのもの の違いでしかないような気がするんだが
そう、紙媒体と違って、1ページの概念が希薄なんだよ。 だから少なくとも俺の周りじゃドキュメントをそんな厳密に定義して使ってるのなんか見たことないし。 だから個人的にページの違いってのの考慮は薄くしてる。
文章じゃなくて、文書だな >Section >文書群の中の節である文書を指す。 >Subsection >文書群の中の小節である文書を指す。 別に節や小節は同一ページ内に複数あったっていいから、 そう読み取れる部分があったとしても、全てにおいてそれが当てはまるとは限らないんじゃね?
>>277 読んだ結果がそれなんだから、これ以上は平行線だろ。
文書を複数か単数かと見倣すのは意味しかないというのが
>>275-276 のような流れで個人的にFAになってるからなあ。
>>278 は悪いが「そう」とか「それ」とか全然わからん。
bookmarkは使わないようにします。
答えが出なさそうだが、Startもどっちだ? 一連の文書のスタート? それともサイトのルート? >検索エンジンに対して、最初に読ませたいと著者が想定している文書 ってどっちとも取れるよな。
helpは?
なんでわざとどっちとも取れるような表現をしているの?もっと強く縛って!
>>281 contentsもそのページ単体を目次の項目とするものを指すから、
前者?
明確に縛ってないって事はどっちでも良いって事だろ。
やっぱり ストリクターは マゾだ な
やすまな
(th)(th)(th)(th) (th)(td)(td)(td)(td) (th)(td)(td)(td)(td) (th)(td)(td)(td)(td) こういうとき左上はどうすればいいですか? tdで中身には何も入れないのでいいですか?
はい
ありがとうございますm(td)m
どういてこましてm(tr)m
link要素のrel属性値でreferenceだかbibliographyだかはないの?参考文献。
>>292 参考文献が関連文書のbookmarkでもええんでないの
「.htaccess質問コーナー」スレが落ちているんだが、誰かたててくれないか? え、おれ? 立てすぎでダメだったよ。 ## もしかして.htaccessはWeb制作じゃなくてサーバ技術系の板なのか?
サーバの設定ファイルである以上自宅サーバ板なんだろうねぇ。
しかしちょっと検索してみると、「Web制作」(以前)と「UNIX」にしか存在していなかった。 これはw
297 :
Name_Not_Found :2006/08/11(金) 01:13:09 ID:c+lvj6zQ
imgタグのsrcの画像ファイルが取れなかった時 出てくる×印(通称「ペケポン」)、 出さないようにする方法はございますか。
スレ違い。なんつか、お前見てると物凄い腹立ってくるな。
299 :
Name_Not_Found :2006/08/11(金) 01:37:41 ID:c+lvj6zQ
imgタグだってよw
「タグ」という言葉自体は間違いではない。 ときどき「要素」と「タグ」の区別も出来ていない奴が居るんだけど…… imgタグ: <img> と </img> という記号のこと。 img開始タグ: <img> img終了タグ: </img> img要素: 文書を構成する「img」という要素。 語弊があるかも知れないが、imgタグで囲まれた部分全体のことだと思ってくれれば良い。
記号じゃないだろ
303 :
pi8027 :2006/08/11(金) 04:03:58 ID:zP/zMbZP
>>297 其れはIEの仕様だからどのようなマークアップが適切なのかを語り合うこのスレとは全く関係の無い話。
と云うか、何故IEはimg要素のalt属性を表示しないのだろうか。代替テキストを表示しないのは如何かしている。
とIEを批判してみるテスト。
ポコペン
別にええやん。関連文書なんやから。 306って同一文書オンリーの人?
>>303 糞コテ名乗ってまでスレ違い誘導済みの質問に答えるなカス
>>307 同一文書かそうではないかではなく、関連文書そのものではないじゃない。
文書名・著者名だけが羅列されているだけじゃない。
>>301 img要素に終了タグはねえだろ
ってツッコミはなし?
>>292 参考文献は一覧ページを作って
appendixでリンクさせるのが筋じゃないか?
appendixは巻末付録のことではなくて? 参考文献も含め巻末付録としてappendixに記載? appendixってかなり汎用的?
論文読んだことないの?
中卒には無縁
今度はappendixの話になってる。
>>293 が違うことは確か?
結局bookmarkの使い方がわからない・・・。
helpは何を書いてる?
>>318 helpはヘルプコンテンツらしい。
例えば、サイト全体のヘルプコンテンツはサイトの概要などについて纏めた文書。
とん。よくある「このサイトについて」みたいなやつか。
contents index glossary copyright appendix help bookmark これらは全て同列であってどれかがどれかにぶら下がるということはないのでしょうか。
複数にわたるページ群のうちの一ページなのか とある一ページ中のアンカー識別子を与えられた要素なのか といった対象の範囲も気になるけど そもそも対象そのものはどういうものなの? しおりは著者が挟むものじゃないよね? って、しおりには > (2)案内書。手引き。 > 「旅の―」「英文学研究の―」 って意味もあるのね。でもどっちにしろよくわからんです・・・。
>>323 ファイル(紙を入れる方ね)に挟む、
出っ張りのある仕切りを思い描いておけばよいんじゃないの?
あれよりこっちでいうbookmarkは使い勝手がよいだろうけども。
(つまり、完全に同一ではない)
自分でリンクタイプを用意して利用する事も可能だが…使っている人は挙手。 多分いない。
>>324 ファイルの仕切りって、もともと付いてるポストイットみたいなやつ?
あれはユーザが自由にラベリングできるけど・・・。
もしそういうイメージで著者側が貼り付けているものというと、
電話帳や辞書の五十音順などで色分けされているアレを連想してしまう・・・。
本の側面に階段状に色が付けられているアレ。
>>326 ポストイットじゃなくてファイルされる紙と同じサイズの板。
で、ファイルにまとめられた文書全体がサイトの文書全体に
対応するものと考えてくれ。
> 電話帳や辞書の五十音順などで色分けされているアレを連想してしまう・・・。
> 本の側面に階段状に色が付けられているアレ。
そっちの方が適切なたとえかも。
辞書のそれはindexなんだろうけど、形としてはそんな感じかな。
文書をまとめて提供する側が、目安となる地点を提示する、
という形は件のbookmarkと同じだろうと思う。
>>309 >文書名・著者名だけが羅列されているだけじゃない
これを言えるってことは質問者本人なんだろうが、
もっと具体的な例を出せよ。
>重要な開始点 これが恐らくhnやtitleを指すだろうから、 参考文献でもいいって意見は見たことあるしわかる。 「そのドキュメントに関連する大事なタイトル」だから。
> A bookmark is a link to a key entry point within an extended document. bookmarkってのは、ひとつの長い文書における主な読み始め箇所へのリンクですよ。 > The title attribute may be used, for example, to label the bookmark. title属性は、例えばブックマークのラベルとして使われます。 > Note that several bookmarks may be defined in each document. ひとつの文書毎に複数のbookmarkが定義されうるから注意しましょう。 長い文書は読み始める点が先頭だけじゃ面倒だろうから、 読みはじめとなりうる所にエントリポイントを設置したけりゃ bookmarkをつかえよ、ってことだな。 ページ内に見出しを設置する代わりにこれ使えればいいが、 階層化はできないよね?これ。
>>332 そのページに関連する他人のドキュメントを
<link rel="bookmark" href="
http://unko " title="うんこ" />
<link rel="bookmark" href="
http://haisetsubutsu " title="排泄物" />
<link rel="bookmark" href="
http://hun-nyo " title="糞尿" />
と複数並べるって意味?
<link rel="bookmark" href="sankoubunken.html" title="参考文献" />
って意味で言ってたんだと思ってた。
てかan extended documentは自分のドキュメントじゃなく他人のドキュメントであってもおk??
bookmarkの姿が見えてきた?記事が長くなければ使わなくてもいい属性値? ちなみに漏れはentry pointを記載箇所と解釈していた 中学英語しか知らないからニュアンスの差がわからない
1ページ限定者であっても外部ページおKという認識のようだが
>>255
>>335 記事が長いにも
・1ページが長い
・複数ページに渡るような長さ
の2案が出ている
>>333 階層化というか上からまたは下から順にordered listになるの?
>>334 俺的には上のイメージだが、W3Cとしてはどっちのケースも許容しているような気がしてならない。
340 :
330 :2006/08/11(金) 18:48:29 ID:???
>>336 あ、一ページ限定かそうでないかはどっちとも言ってないっすよ。
というかどっちかわからんです。
あと
>>255 の言う「外部ページ」って自サイト内の別ページのことだと思う。
>>334 の上段の例は他人のサイトのことを指してます。
>>334 の上だとするとtitle内に著書名も著者名も書くの?
参考文献で書くことは分野によって違うだろうけど
少なくとも「書名・著者名or編者名・出版年・出版社」は書かないといけなくない?
日々数行程度の覚え書き風日記しか書いていない俺には関係ないな。
文書全体(サイト全体)の参考文献は
>>311 ?
各章の参考文献はどうかって話?
ほかのやつはページ内だろうがページ外だろうが
少なくとも自分のサイトのページを参照しているのに
bookmarkだけ
>>334 の上っ側のようによそのサイトを参照するの?
他の属性値に倣うならbookmarkだけが334の上だという捕らえ方は不自然だよね。
>>333 で決まりか。
>>337 の二案はおそらくどっちでもいいと思う。
複数ページにわたる場合で別ページを参照するときも識別子を付けて
foo.html#hoge
って参照したほうがよさげな気がする。気がするだけ。
>>344 link要素は他の文書との関連付けだから其の文書から見た参照記事なども有得るのでは?
bookmarkがrev属性で指定されることもあるんだし、 文書そのものもbookmarkとなりうるんだろうな。 文書1ファイルの特定箇所だけじゃなくて。
contentsがサイト全体の目次で bookmarkがサイト内の一コンテンツの目次?
>>349 rel="bookmark"を複数にできないのでは?
>>348 >>333 で、かつ
> 記事が長いにも
> ・1ページが長い
> ・複数ページに渡るような長さ
> の2案が出ている
の
> ・1ページが長い
場合?
>>350 >>333 > Note that several bookmarks may be defined in each document.
ひとつの文書毎に複数のbookmarkが定義されうるから注意しましょう。
それを根拠付けるものはこれ? > カレントのページ外のリソースとカレントのリソースを link 要素で関連付けるための > linktype は他にちゃんと用意されているじゃない。
>>347 に補足。
文書1ファイルをbookmarkのひとつとして書く状況ってのは、
目次ページからたどれるページが100ページ位あって、
そのなかの主要な読み始め箇所を目次で示す場合くらいだろう。
参考文献や関連文書を示す、だとかは明らかに管轄違いだな。
>>348 外部のページを指さないんだったら、Copyrightともども
meta要素の管轄になってるだろうよ。
イイーンダヨ
なんか勝手に決められてる感が強いんだが。
bookmark自体ブラウザであんな言葉の使われ方をしたように
我々が思っている所謂「しおり」の使い方じゃない。
だから
>>348 は強引すぎ。
>>341 本の場合だったらISBNコードさえあればタイトルはテケトウでいいんでね?
cite属性とtitle属性のようなもん。
>>343 >ほかのやつはページ内だろうがページ外だろうが
>少なくとも自分のサイトのページを参照しているのに
前に2つのサイトで交替で小説の続きを書くという企画をやってて
prevとnextで別サイトが割り当てられてたのを見たときには感動した。
しただけ。
link要素って「文書の繋がり」を示すものだから 内部だとか外部だとか1ページだとか多ページだとか 区別することがナンセンスな気がする 繋がってればオールオッケー
わかってないな
>>348 なんでわざわざ冗長のあるものを拡大解釈してそれ限定にしなきゃならないんだ?
「やるものでしょ」「ありえんでしょ」はおまえの常識でしかない。
わかってないな
さりげなくcontentsとindexの違いもわからん俺・・・
>>367 contentsは目次。例えばh要素をツリー化した一覧。
indexは索引。フレーズの役割を示すインラインテキスト要素の一覧など。
ともにハイパーリンクを提供して本文中に移動できるようにすればいいと思う。
いやあの、そこまではわかるんだけど、 hn=フレーズ=文章の要約だと思ってるからおかしいんだろうか・・・
index.htmlって「目次ページ」って訳されてるしそう使われるけど、 そっちの意味でlink要素のindexを使ってる人がいてもおかしくないしいいんじゃないかとも思う。
index.htmlは各ディレクトリに置いています。 そしてindex.htmlまたは他に設定したindexファイルがなければアパッチは Index of /ディレクトリ名 としてファイル一覧を表示します。
indexはむしろcontentsじゃなくてstartと混同している人が多いと思う。
>>371 の理由から、一つのディレクトリにドキュメントファイルをまとめて置いた場合、
index.htmlが最初に表示されるから。
>>372 だから普通そこが目次ページになるだろ?
>index.htmlって「目次ページ」って訳されてるしそう使われるけど、 最初に表示されるページにcontentsもhelpもcopyrightもいろいろ載せているところは多いと思う。 だから <link rel="start" href="index.html" /> <link rel="contents" href="index.html#contents" /> <link rel="help" href="index.html#help" /> でいいと思う。
>>373 目次(のようなもの)をindex.htmlに載せた場合はそこが目次ページに”も”なるね。
でも索引ページに使われてることは見たことがないindexページ
>>376 あーそうそうww
で、主な使用目的が「目次のような」だから
indexをディレクトリインデックスに指定してる人はindex=目次と考えてたんちゅうかと。
つーかディレクトリインデックスってどう考えても
>indexは索引。フレーズの役割を示すインラインテキスト要素の一覧など。
ではなく
>contentsは目次。例えばh要素をツリー化した一覧。
のほうだよな。格納ファイルの一覧。
ホームページはサイト全体という意味として使われている、と同じ論理展開か。。
百姓読みも今では正しい読みとして使われているものもあるけど。
誤用でも使い続ければいいことあるかもね
>>377
・・・・結局わからないということがわかりました・・・
何この流れ。blockquoteはインデントとして使っている人が多いしむしろそっちの意味だよなとか言い出しそうだな。 多くの人がhnを文字を大きくするために使っています、とか。
そう思うのはお前だけ
これはきっとあれだ、さっきまでの言葉を狭めて定義しすぎてたやつの反動だ。
むしろこの流れで思ったことは、 厳密なストリクタはスタートページな目次ページをcontent.htmlかなんかにして index.htmlはちゃんと索引ページにしているんだろうかということなんだが。 俺はしてない。
DirectoryIndexを変更しようかと考えたことはあった。 考えただけで終わった。
つうかgoo辞書によると、 index=目録という意味もあり、 目録を牽くと=目次じゃん。
今までも沢山語られていることなんだが、仕事でWEBをやってると どうしてもクラ都合でデザイン優先になってしまうことが多く バリで何とかしてるレベルで、どうしてもストリクトに仕上げられない。 反動で個人サイトはストリクト。
つ【チラシの裏】
>>384 基本的に自己満足だからな。
そこまでやってる奴は居ないのに、
俺は厳密にやってるみたいに言ってる程度で終わってるのが大部分。
だけど自分もそうなのに、妥協の話になるとスレ違いとか言い出したり、過剰反応しだす。
ここはこうした方が仕様的に好ましい『筈』レベルの話でもね。
>>387 無理に完璧なStrictにする必要は無いでしょ。
できるだけStrictを意識しながらデザインを実現すれば十分かと。
Strictを実現しながら求められるデザインを実現できない
htmlやcssとかの実装が問題だってだけだし。
>>389 ま た お ま え か
過剰反応されてるのはそういう煽りだと気付け
ぶっちゃけ、どっちも大差ない
なんでlink要素のrel属性値indexとindex.htmlを無理やりごっちゃにしようとする人がいるの?
indexという言葉が目次たりえるかどうかの話だろう。
目次⊂索引だと思われ。 順序が内容物の並び順でない五十音順とかに限り索引以外の何物でもなくて、 索引も並び順が内容物と一致するなら目次と言って差し支えないだろう。
apacheはディレクトリ内にindex.html(などのファイル)がなければ apacheが標準で用意したものを使ってディレクトリ内のファイルインデックスを表示する。 ファイルインデックスはファイルの一覧、羅列。つまり索引。 index.htmlは本来はそのapacheが標準で用意したものを使わずに 自由なレイアウトで表示させるためにある。 それを、index.htmlにアクセスしなくても/にアクセスしたらindex.htmlが表示されるから これをstartページにすればurlが短くなるしいいんじゃね?として使う人が増えた。 さらにstartページにcontentsを載せる人が増えた (というかわざわざcontentsを別ページに分けるほどではなかった)から 英語の意味をよく理解しないものたちによってindex=contentsという認識が作られた。 contentsは本文の内容をわかりやすく表記した表題が階層化されて序列されているもの。 ただアルファベット順、五十音順、種類順に単語(場合によってはファイル名)が羅列されている索引とは違う。 表題hnに本文を表した意味のある短い文にせずぶっきらぼうに単語だけを書いている人も多いようなので ますますindexと混同されやすくなっているのかもしれない。 とペットのファルコン(雑種犬)が寝言で言ってました。
すごい飼い犬だな。俺によこせ。
歴史の改竄の場面を見た
ネバーエンディングストーリーの如くだな。 初めて映像でファルコンを見たときには あまりに犬っぽくてイメージにそぐわなかったものさ。
まったく別の単語をどうしても結び付けたい人がいるようだな。 理科や社会の参考書(資料集か?)を見てみろ。 目次と索引があるだろ。同じか?
ネバーエンディングストーリーのファルコンって犬じゃないの?犬だというイメージしかない。
別物だけど全く別ではなくて
>>386 や
>>394 のようなものだろ
そこまで完全に別物にする理由も完全に同じ物にする理由もない
>>401 は学校でもらった資料集でも見ておきなさい。
朝から拡大解釈したがる人だなあ・・・
>>390 これこそ過剰反応してるかもしれないけど、もしかして
>>49 のこと?
だとしたら自分だけど
>>389 ではないよ。
あの発言は、不適切だったと自分自身反省してる。
ただ感情を吐きつけるだけで、相手へ伝えようとする配慮が決定的に欠けていたと思う。
申し訳ありませんでした。
一つ訂正したいのは、自身が書いたレスに過剰反応されたとは思っていない。
前スレのデザインと論理構造の話を見てそう感じたと言いたかったんだ。
言語の問題ではなく概念の問題。
ファルコンが犬に含まれるかどうかだな。
含まれる
日本的勘違い概念を重視するならウェブサイト全体をホームページと呼ぶような 独自の文化を作り上げていけばいけど。それはそれでいいけど。 でもそれをここで主張されても。
そもそもドラゴンと竜は別物。
>>411 少なくとも日本語の概念が間違っていると主張するならば
日本語の参考書を参照しろというのは矛盾している。
>>412 それを言うならドラゴン=竜と龍だろう。
でもファルコンのうなぎ姿は東洋の龍がモデルらしいが。
客観的なものを何も参照せずに自分の価値観だけで全てを決定付けようとしている人がいる。 少なくとも英英辞典は引いて。 西洋で言うところのドラゴンと東洋で言うところのドラゴンは別!ファルコンは犬とウナギのキメラ!
> ファルコンは犬とウナギのキメラ! 謎が解けた ってウナギ犬じゃないか! ウナギベースの犬か犬ベースのウナギかでこれほど姿が変わるのか
別物だという価値観は認めた上で重なるケースを話している人間と 重なるケースを完全に否定している人間と どっちが自分の価値観だけだ?
>>415 別とは言っても元は同じ。
恐竜と天災。
ストリクタって竜と龍まで定義しなきゃ気が済まないのか・・・・・
helpは? Refers to a document offering help (more information, links to other sources information, etc.) のlinks to other sources informationってリンク集のこと?
ちがーう、西洋ドラゴンも元々は蛇系だったんだー!
ファルコンって手足あったっけ
display:none; これってstrictの考えかたからはずれませんか? 教えろよボケ。
そもそもファルコンじゃなくて原作はフッフールだから。
>>424 見た目と論理構造は切り離して考えるべき。
>>387 クライアントサイドのXSLTでStrictなXHTMLから適当なXMLに変換。CSS1の範囲でもけっこういける。
Firefoxはもちろん、IEも5.5から対応してるよ。Operaは9からだけど。Safariは1.3から。
>>421 >
>>311 ,
>>319 とあるが。pi8027は・・・・・・
もしかして、
pi8027はコミケに行っているんじゃないのか?
と言いたかったのですか?
漢字の読み仮名を何らかの形で記述したいのですが、 文書型の関係でruby要素を使えない場合にはどのように記述するのが適当でしょうか? 1. 香具師(やし) のように括弧書き 2. <dfn title="やし">香具師</dfn> のように記述 3. <span title="やし">香具師</span> のように記述 4. <a href="#YASHI">香具師</a> のように書いて、別の位置に定義リストを使って記述
>>432 ルビの使えない日本語文書の場合は何にもなくただ「香具師(やし)」だと思われ。
これはStrict云々ではなく慣習だが。
>>430 IE5.5はxsltの名前空間をIE専用にして、MIMEもIE独自のtext/xslにしないといかんじゃないか。使えない。
>>432 "香具師(やし)"だと音声環境に優しくない様な気がするので2番を選ぶ。
>>432 本文と同様に伝えるべき情報と捉えるなら1.が妥当。
あくまで補助的な情報と捉えるなら3.でも構わないかな。
ただ、それでtitleの情報を閲覧者が入手しても読み仮名と認識できるかという問題もあるね。
下手にやるより、慣習として読み仮名と認識できる1.が無難かもしれない。
>>434 十分、Strictじゃない?
rubyモジュールの論理構造を模倣しただけだし。
>rubyモジュールの論理構造を模倣しただけ これだったらXHTML1.1にする方がStrict的。
確かに、その方がより良いね。 でもだからと言ってXHTML1.1以外+spanが非Strictかと言うと違うかと。 その文書型が表現できる要素で、論理マークアップできていれば十分Strictと言えると思う。 class="rp"部分が少し気にならないではないけども。
ない要素を無理矢理spanでなんとかしようという根性がStrict的ではないと思うんだが。 だったら「footerって要素がないからdivで作るね!」と同じような。 ようなちゃん。
ようなちゃん萌え
>footerって要素がないからdivで作るね!
別に構わないと思うよ。footerを論理構造と言えるなら。
よくあるdivセクションなんかも「sectionって要素がないからdivで作るね!」ってことだし。
仕様には無い。だけど明示したい。
そんな構造を示すためにdivやspanを使えばいいんじゃない?
>>434 は、単語と読み仮名という構造を明示したかったからspanを使った、と。
フッタもルビも論理構造というのは微妙。 特に括弧。
フッタは、位置を示すんでなければHTML的にはheadが担当する部位なんだろうね。 括弧が気になるというのも分かる。 rubyモジュールの構造は、互換性優先と言った感じだし。 そういう点では、Strictと言うのはつらいかもしれない。 一応、単語(読み)をマークアップすると考えれば括弧は読みじゃないだろうという観点で別にするかもしれない。 括弧以外はrubyの構造も、そんなに変ではないと思う。 すっきりするのは、abbrみたいに属性値にすることだけど、 ルビは表示するのが前提の情報だろうから、読みも属性にせずマークアップするべきじゃないかな。 そして、単語と読みを一纏まりとしてマークアップすれば、必然的にあの形になる。 括弧とrubyという物理要素っぽい名前が足を引っ張ってるけどね。
でも「文書ありきでマークアップ」だと、括弧がないほうが不自然な罠。
IEさえなきゃtitle属性をcontentプロパティで書き出してうにゃうにゃして ってできそうだが、俺も振り仮名も括弧もあったほうが自然言語っぽいので現状のruby支持。
自然言語かどうかは関係ないと言えばない感じじゃない? 所詮ただのマークアップでしかないんだし。 ・ほげほげ ・もげもげ ・もげら って文書は・を記号としてHTMLで吸収しちゃうし、 既に元の文書とは別物になるって考えてもいい気がする。
>>447 非常に意味不明なんだが、おまえは「・」を記号ではなく意味ある言葉だと思ってるのか…?
>>445 その括弧の部分をどうHTMLで表現できるかって話をしてるのでは
例えば元の文章で、「強調として」括弧を使ってるのならemなりstrongなりを使えば良いわけだし
()書きはむしろ弱調で以下ループ
>>447 吸収するも何も、買い物リストのメモでわざわざ・まで書く奴なんて見たことない。
qの引用符は?
引用符は普通は地の文に直接書くのに、HTMLではUAが付加するように指示されているのね。
引用符は普通は地の文に直接書かないと思う。←こんな感じで。 特に手紙のような手書きだと絶対書かない。書く人もいはするだろうけど。
>>455 それ別に引用していないじゃん。文面をまねただけじゃん。
強調は太字や斜体として表示されたりしているけど 縦書きの活字などにおける文字の横に付く波線や傍点と同じ?
XHTML2ではUAは引用符付けちゃダメなんじゃなかったっけ?
約物は地の文に書かせろ。 そうじゃないと句点や読点や感嘆符や疑問符などとの整合性が取れなくなる。プンスカ!
>>456 "引用符は普通は地の文に直接書"かないと思う。
>>458 地の文でもCSSでもどっちでもいいから必ず付けろとしか言ってない。
>>462 それは逆に言えば*明確に区別さえつけばいいから*blocuquoteではインデントで示しているように、
引用符自体は何でもいいし(括弧やクォーテーション等文化に依存する)ただのスペースでもいい。
だからCSSという結論が昔出てたような。
>>462 そう。分野によっては多少違いがあるかもしれないが。
blocuquote>blockquote ちょうど無知のような誤字orz
パンくずリストはstirct的にはNGなんだっけ?
ナビゲーション類はhead内では実現しきれないので 本文とは別のグローバルなセクションを作り その中では各種ナビゲーションや検索やその他なんでもあり ・・・というルールが俺の中で芽生え始めてきています・・・
>>467 パンくずリストは現在のドキュメントへの階層を表すものだから
<ul>
<li><a>第一階層</a>
<ul>
<li><a>第二階層</a>
<ul>
<li>第三階層(いまここ!)</li>
</ul>
</li>
</ul>
</li>
</ul>
などとしてるけど、階層は本来はlink要素のChapter、Section、Subsectionなんだろうね。
>>469 階層だし移動順序だからulじゃなくてolが好ましいと言われている。
どこで言われてんの?olはフラットじゃない?
>>471 過去ログ見れ。
それとストリクタは面倒臭がりが多いから
入れ子じゃなきゃならないところはするけど、
入れ子にしないで済むのならそちらを選択すると思う。
あれってこのスレ内だけでそう言ってただけじゃないの? どこか引用元を参照してたっけ?違った? 過去ログ見てくる。ごめん。
毎回そうやって同じ議論を繰り返すんだから、 誰かまとめとけよ。
お、言いだしっぺの法則か。
>>470 第一階層→第二階層→第三階層という深度を縦の序列で示せるからフラットじゃないとも言える
というかパン屑ってそれよりもルート→カレントのパスを示す意味合いが強いから。
471宛ダターヨ
>>469 <ul>
<li><a>第一階層1</a></li>
<li><a>第一階層2</a></li>
</ul>
こういう構造になりうるなら、それがいいと思うけど
パンくずリストは、そうならないリニアなデータかと。
現在のドキュメントへの階層=HTMLの階層では無いから、
リニアなデータを表すのにHTMLを階層化する必要は無いと思う。
だから自分だったら、やはりolかな。
ページの本文とは関係のないサイト共通の部分もbody内に書いてもいいんじゃない?そして書いてるよ。 って人は、何を書いていますか?
あ、Strict的に書いてもいいって思ってるわけじゃないけど、 別の観点から、文書の責任として社会的にって意味。
ToCと使用しているスクリプトのバナーの一覧かなあ。
自分とこのサイトのバナーのっけてるけど・・・ strictな人ってバナーをあえて作っていない人が多いような
>>483 バナーって、リンクや交流に関するまとめページみたいなのがあれば
本文に関係ないものではないと思うんだ。
グローバルナビにバナー置いてたらだめ?
>グローバルナビにバナー そもそもどういう状態か全く想像がつかんのだが・・・・・
CSSで書き出すならまったくもってどうでもいいと思うが・・・
<a>本文へ</a> か <a>本文</a>へ か って話?読むの面倒だから三行にまとめて。
質問です。ウェブページを翻訳機にかけたときのような、 日本語と他言語が要素毎に交互に表記されるような場合について。例えば <h1>Strict-HTML スレッド 37 <span lang="en">thread of Strict-HTML 37th</span></h1> のような記述を考えているのだけど、どうですかね?上に書いたような感じだと違和感 ないのですが、下のような場合は <p>StrictなHTMLについて語るスレッド。W3C信者もそうじゃない人も… <span lang="en">here is a thread which we're talking about Strict-HT…</span></p> pふたつのほうが自然な気もします。 ご意見下さい。よろしくお願いします。
>>488 こういう議論を見てて思うのは、仕様の理想を追い求めすぎるあまり、
HTMLが誰の為に、どんなものを提供するのが目的かということを
ないがしろにしているように感じられるな。
その議論が発生する理由は、a要素の文字列が何であるかの前に、
body内にナビゲーションが入る事が間違いという認識があるからだよね。
ナビゲーション類は、headに入るべきだって。
だけど、その認識自体が頭で述べたような理想追求論なんだと思う。
この手の話を突き詰めていくと、本当に論文ぐらいしかHTMLでは書けなくなってしまう。
そうした現実と剥離した理想論はW3Cの、HTMLの意図するところではないんじゃないかな。
あくまでHTMLは機械読み取り可能なオンライン文書であり、
機械的に処理するだけの論理構造でもなければ、紙媒体などの従来の文書とも違う。
その従来の文書と違う部分として
本文に埋め込むナビゲーションがあってもいいじゃないって考えの表れがXHTML2.0のnlじゃないかな。
そしてナビゲーションとして「本文へ」という文字列があっても問題ないと思う。
現状nlがあるわけじゃないから、ナビゲーション自体が拡大解釈気味ではあるけどね。
と、ここまで書いて
>>488 の質問に答えていないことに気づいた。
>>489 の言うとおりだと思う。
誤解を与える装飾でなければ大丈夫でしょう。
>>491 なんとも言いがたいけどp二つで、いいんじゃないかな。
でないとHTML上、同じ段落に見えるし。
その場合、h1もpにあわせると
<h1 lang="ja"></h1><h1 lang="en"></h1>
となるけど仕様上、h1の範囲がh1から次のh1とか言われているわけでもないから
これはこれで構わないと思う。
おっかしーだろ確実に。
>>493 さすがにそれはどうなんだろ??
まだspanの方がましな気がする
それかJS w
>>494-495 うーん、やっぱり?
言ってはみたものの自分でも違和感はあるんだよね。
pは、段落として分けてもいいと思うけど他の要素もろもろを考えるとほとんどが厳しいか。
<div class="heading"> <h1 lang="ja"></h1> <h1 lang="en"></h1> </div> <div class="paragraph"> <p lang="ja"></p> <p lang="en"></p> </div> これでおk!
そもそも、h1って複数あっていいんだっけ?
複数あっても問題なくね?
HTML4.01のDTDには、h1は一回だけ!という記述は見つからない。 見つけられないだけかもしれないけど・・・・。
とりあえずh1を複数回使うと検索エンジンにはスパム認定される可能性高いな。
>>492 nlは本来文書にあるべきローカルナビゲーションで使用するものであり、
グローバルナビゲーションを認容するためのものではない。
504 :
491 :2006/08/14(月) 20:40:13 ID:???
とりあえず、spanな方向で何ページか作ってみました。ローカルで。 CSSが使えば span.en { display: block; } とか書いておけばそれなりなんですが、 CSSなし環境(lynxとか)だと、 日本語English と並べばまだ何とか読めますが、これが DeutschEnglish とかだとワケワカランかもです。ruby要素的な考え方が必要かもと思いました。 あとCSSの話はスレ違いだけど、匿名ブロックがいっぱい出来ると気持ち悪いですね。
505 :
491 :2006/08/14(月) 20:41:13 ID:???
>>504 ×:CSSが使えば
○:CSSが使えれば
>>503 書きかたが悪かったかな。それはそうだと思うよ。
そもそもグローバルナビゲーションはheadにすらあるべきじゃないと思う。
保守性の面でも効率悪いし。
でも、nlがグローバルかどうかは問題じゃなくて
body内にナビゲーション目的のリンクが存在するということ。
さっきは失念していたけどmapなんかもそうだね。
ナビゲーションと言う概念が取り入れられているなら、
aにナビゲーション的な文字列を入れてもいいんじゃないかな。
aがないと成り立たない文字列は、おかしいという考え方は
いきすぎじゃないかなと。
本当はパン屑リストが無くてもlink要素があるから全く問題ないんだよな。 消すか。
>aがないと成り立たない文字列 これは誤読してね?
正しくは擬似要素がないと成り立たない文字列だな。 つうかJSでの書き出しのStrict的妥当性については語るのに、 CSSでの書き出しの妥当性については語りたがらない変なスレ。
でも消すと不便なので代替手段を考える。 まあOperaユーザーとパン屑リストは無縁だがな。
>>508 >>488 の議論の中で、それらしいことを書いている人がいて
ナビゲーションは配置できないといった考え方を端的に表してるなと思ってそう書いたんだけど
何の前触れも無く、意味不明な言い回しだったかもしれない。
>>509 JSはHTMLに手を加えるけど、CSSは伝え方(表示方法とか)を変えるだけだからね。
HTMLがStrictでさえあれば、それをどう読者に伝えるのが妥当かはユーザビリティの問題で
StrictなHTMLを語るこのスレの範疇ではないと思う。
>>511 どう伝えるかの妥当性ではなくて、
それをどの要素で実現するのが妥当かという問題。
まあ俺はどっちでもいいけど。
>>488 において>を、aにつけるかliにつけるかということ?
同じくどっちでもいいと思う。
「文書名>」としたければliにつけるし
.. ̄ ̄ ̄
「文書名>」としたければaにつける。
.. ̄ ̄ ̄ ̄
それだけのことだと思うな。
で、どちらが妥当かは
>>511 という話になるかと。
>>513 ・・・・「したいから」するという意見を言うくらいなら黙ってろよとちょっと思った('A`)
意見は
>>511 だよ。
>>511 では伝わらなかったみたいだから補足として具体的に例示したんだけど
かえって回りくどかったみたいだね。
要はCSSの使い方に、HTML的なStrictさは何の判断基準にもならないということ。
>>515 だからそれに対して「伝え方」の問題ではなく「要素としての妥当性」だと言っているのに
また舞い戻ってどうする。
まあそれに関しての妥当性は可能性も頭にない事は分かった。
でも質問者は「それがあることを前提として」質問をしていると思うのだが。
あぁ、なるほど。 CSSにおいて要素としての妥当性はないってレスに対する反論だったんだね。 全然、読めてなかった。ごめん。 ただ、自分には全く見当が付かないんで、 CSSを当てる上で「要素としての妥当性」があるのならば どういった点で、それを考慮しなければならないのか説明してもらえると嬉しい。
>>517 いや、俺も上で言ってるとおり「どっちでもいい」人間なんで、
それがあると考える人間がいるんだろうことまでは推測できても、そこまではっきり分かる訳じゃない。
ただCSSの中でcontentは特殊だって気はする。
それだけで「文意を変えられる」から、それを装飾の範囲で収めてしまうのには俺でも抵抗あるね。
この場合は「>」程度じゃそんな文意は変わらないと思うけど、
その「>」に文の意味として「へ」があると考える人なら、文意が変わることまで許されるのか、
と考えるのは分かる。そして文意が変わることが許されないならば
「本文へ」が駄目で「本文」ならアンカーとしてOKなら、
「>」をa要素で実現するのは間違いなんじゃないかと思うと思う。
多分。
ああ、だからそもそも「CSSで文意を変えること自体に反対」かも。 と書いてて思った。マッチポンプスマソ。
確かに文章すら付け加えられるcontentは、特殊に見えるね。 基本的には「」だとかの記号をつけるのが目的なのかな。 ただ、contentに限らず使い方次第で誤読させてしまう危険性はあるわけで そういう意味では同じなのかなとも思う。 どちらにせよ文意を変える事に反対というのは同意。 >の適用位置は、意見の異なる人が出てこないと これ以上は、なんとも言えないね。
あえていうならば 文書名>  ̄ ̄ ̄ だと思う 「>」までふくまれているのは違和感感じる
┌───┬────┐ │Web │Safe │// │ │ Color\// └───┴────┘
┌──┬──-──┐ │WEB │Safe │// │ │ Color\// └──┴─-───┘
崩れる…orz
なにやってるの?w
┌──┬──-──┐ │WEB│ Safe │// │ │ Color \// └──┴─-───┘ こうしたかったのか?
527 :
488 :2006/08/15(火) 20:42:57 ID:???
微妙にスレ違いだったんだろうか・・・
「<a>本文へ</a>か「<a>本文</a>へ」だったら確実に「<a>本文</a>へ」だったんだけど、
(だから
>>513 のようにアンカーに含めたいかどうかは既に決してる)
CSSで「へ」を書き出せばOKなのか、そもそも「>」は「へ」になるか、
ということをどう思うかを聞きたかったんだけど、あんまり興味をそそる話題ではなかったようで。
そもそもCSSでの書き出しを単に装飾としか見てない人が多いんだね。
個人的には
>>518 のような感じなので、「へを」aの外に追い出すように
やっぱり「>」はaの外に追い出した方が適切だとは思った。
でもそういう意味で他人から見た場合は、どちらもStrict的に変わらないことはわかったよ、d。
>>492 =506?
ナビでもローカルナビは本文に関係するものだから入れるべきだと思うよ。
すべてがheadに追い出せるわけでもない。この場合はできるけどね。
そして保守がどうかという問題はWeb管理の問題であってStrcit性とは関係ない。
そういえば序列リストでのパン屑リストの>も aでではなくliの方で追加するな。>はaに含めない。
なにがやりたかったのかよくわからんけど、ほのぼのしたw そんなバナーってあるんだっけ?
それで↑の人は作ったのかw
WebセーフカラーはStrict的なんだろうか。
ユーザビリティの範疇でしょ。 Strict的には色がどうのこうの、という概念は大した意味を持たないはず。
そもそもHTMLは見てくれを規定するもんじゃないからね
×Strict的には色がどうのこうの ○Strict的にはウェブページの色がどうのこうの
533に答えることが?スレ違いの厭味?
一連の流れだ。
534に限局して言うことじゃないな。痛いところ突かれたわけでもあるまいに。
540が非常に意味不明な件
痛いところを突かれて顔を真っ赤にして焦ってたからだよ。 typoかね。
543 :
Name_Not_Found :2006/08/16(水) 05:54:28 ID:N1+ieQDm
質問がこちらでいいのか分からないのですが こういう表を書くにはどうしたらよいのでしょうか。 ┏━┳━┳━┓ ┣━╋━╋━┫ ┃┼┣━╋━┫ ┃┼┣━┻━┫ ┗━┻━━━┛ ※「 ┼ 」は無視してください(空白のつもり)。スペースだとずれるので代わりに入れただけです。 1段目:thead要素 2-3段目:tbody要素 4段目:tfoot要素 ↓これでは上手くいかないみたいです。 <table> <thead> <tr> <th>表見出し1</th><th>表見出し2</th><th>表見出し3</th> </tr> </thead> <tfoot> <tr> <td rowspan="3">系1</td><td colspan="2">合計</td> </tr> </tfoot> <tbody> <tr> <td>値1</td><td>値2</td> </tr> <tr> <td>値3</td><td>値4</td> </tr> </tbody> </table>
なんでこのスレで・・・
>>543 スレ違い甚だしいが、結論から言えば 無 理 。
そもそもtbodyとtfootがセル結合だなんてデータがおかしすぎ。
>543まず、適切なスレで質問しましょう。 それはStrictには遠過ぎる。突っ込まれまくりの叩かれまくりになるよ。
XHTML1.0でdd要素内部にhn要素が認められるのに何か違和感を感じるのですが自分だけでしょうか
うれCY
>XHTML1.0でdd要素内部にhn要素が認められるのに何か違和感を感じるのですが自分だけでしょうか 明らかに不自然だろ
blockquote後のcite要素とかの出典元って、何にしてる? やっぱりul?それともp? |引用引用引用引用引用引用引用引用引用引用 |引用引用引用引用引用引用引用引用引用引用 |引用引用引用引用引用引用引用引用引用引用 |引用引用引用引用引用引用引用引用引用引用 「●●●」より ↑こういう奴。
神崎さんとこでは <blockquote> 〜 <cite>〜</cite> </blockquote> ってやってたような。 でもこのスレ的にはblockquoteのcite属性title属性だけで表現するのがいいみたい。 一部の視覚系UAでは表示されない場合もあるけど関係ない。
>>553 ごめん、citeをblockquoteに入れるのは俺的にはNG。
ソース的にはcite属性とtitle属性だけにもしてる。
んだけど、それを後ろにJSで書き出してるのね。それをどうしようかと。
つーかciteをblockquote内に入れるにも構造は必要じゃないか。
Javascriptでhtmlを出力するのも結局出力後の構造がストリクトじゃないとだめだよね てかポップアップ系?
>>556 仕様的にはValidにしなきゃならないだけでStrict的にする必要はなく、divでも構わない。
が、やっぱりよりStrict的でありたいというだけで。
ポプアプじゃない。
<dl> <dt><cite>...</cite></dt> <dd><blockquote> ... </blockquote></dd> </dl> とかは?
>>558 引用文主体だから意味的には逆じゃね?
できないけど
ul-li
面倒だからpreでいいよ。
意味不明
・・・みんなciteをblockquoteの後ろに付けるということをやってないということだろうか。
>>564 そのciteを置く適切なブロック要素がないんじゃね?
そだね。 〜うんたらかんたら。</blockquote> <p>どうしたこうしたは<cite>どこそこ</cite>からの引用ですが(ry</p> とかならいいんだけど。
ある意味HTMLって適切なのがないばっかりだと思うが。 箇条書き一個に一票。
>>566 それはまあ本来の目的の使い方ではあるね。
元々blockquoteとの関連づけなんてまるで考えられてない要素だもんな。
address 要素を使うっていうのも、address 要素の意味とは離れてしまうかな。 <blockquote> <address>どこそこ</address> </blockquote> みたいに使う。
KAWASAKI
> 元々blockquoteとの関連づけなんてまるで考えられてない要素だもんな。
HTMLでおおまかに文書の構造が定義できる、という感じじゃなくて、
元の文章から人が構造を読み取るのを、機械が補助する、という感じなんだよな。
>>569 それは単に仕様違反だろ。
citeにしろaddressにしろ、引用元にはなかったものを blockquoteの中に含めてしまうことが問題だーって話なんじゃないの?
よし!これだ! <div class="引用ブロック"> <blockquote> 〜引用〜 </blockquote> <p><cite>引用元</cite>から引用しましたよ。pじゃなくてulとかでもいいと思うよ</p> </div>
「blockquoteの中にciteを入れれば、その引用部の引用元を示せる」 っていうのはただの思い込みだもんな。 実際には、cite部まで引用だって意味になってる。
さすがdiv、汎用性ありまくりんぐ
>>570 HTML 4.01 では「ADDRESS要素は、文書全体、あるいはフォームなど文書の主要部分に関する問い合せ先を示すのに用いられる」んだってさ。だから blockquote という文書全体でもなく form などの主要部分でもないから使えないんじゃないかと考えたわけで。
ちなみに cite 要素は「引用か、他のリソースへの参照であることを示す」んだと。……こっちは既出かな。
やっぱ div 使うのが楽なのかね?
質問者は別に関連付けについて聞いてる訳じゃなく、 ><p><cite>引用元</cite>から引用しましたよ。pじゃなくてulとかでもいいと思うよ</p> これのどの要素が相応しいかってことを聞いてるだけのようなのにおまいら流石だw
だからそもそもいらないの!blockquoteの属性だけでおk どうしても付けたいのなら何でもいいよ
だけどblockquoteと関連付けられていないのでdivでまとめるなりしなさいよ
つまりはもともと blockquote 要素は cite 属性を持ってるんだからそれ使えばいーじゃねーか、cite 要素やら address 要素やらはそもそも使う必要がないと。
そういう意味?
>>579
>>578 blockquoteの中に入れる阿呆のせいで
質問の一歩後ろから話が展開しただけです。
何度も繰り返されているこの話題の、今回の発端はどのレス?
一歩どころか百歩後ろの議論になってる希ガス
過去スレ嫁、で終わりじゃね?
中に入れる入れないはあったけど、 citeを何に入れるかまであったっけ、記憶の彼方。
cite要素使わないよ。cite属性とtitle属性だけだよ。 どうしても使いたいのなら <p>以下は<cite></cite>からの引用です。</p> <blockquote></blockquote> <blockquote></blockquote> <p>以上のように<cite></cite>に書かれていたわけですが、…</p>
>>590 Javascriptで書き出そうが元からだろうが要らんという話だろ。
citeは、至近のblockquoteの引用先を示すためという感じじゃなくて、
文章中の、参照や引用元を意味するテキスト片をそれと示すためのものだろ。
引用元を表示させることに意味があるなら直接
>>589 のように書けばいいんじゃない?
あってもなくてもいい、直接書く必要はない、意味がないと思っているからスクリプトで書き出してる
としたら、そもそも書き出す必要もないんじゃ・・・?
とにかく
>>552 の形で表示したい、というレイアウト優先志向だから何を言っても無駄
レイアウトは意味不明
「レイアウトは意味不明」という書き込み自体が意味不明です 端折らないで書いてください
またなんか妙な方向に・・・ 補助として書くこと=意味がないんだったら、そもそも補助にしようとは思わないだろう。 でも本文として書くべきものでもないから補助機能で、 なんてのは引用のダブルクォーテーションと似たような位置づけ。 本来「引用部分をしっかり見分けられるようにすること」なんてのはStrictの観点からは必要ないが、 それでも引用符やインデントが本文ではない部分で明示するよう仕様として明記されたように、 「絶対に必要な本文」の部分と「補助として付けた方が社会的に好ましい」部分と 「補助としても必要ない完全な装飾の部分」がある。
引用符はスタイルシートでご自由に。content。 blockquoteのcite属性title属性もスタイルシートでご自由に。 実装の話はスレ違い。 ってか過去スレ
何で実装の話になる。 書き出すときのマークアップの話だろう。
引用符はご自由にじゃなくて付けなきゃならなかったはず なのに本文に書いちゃならない不思議
「補助として」のqの引用符もblockquoteの引用元もstylesheetの役割 スタイルシートだから「書き出すときのマークアップ」はない もしそのことに対して一部の視覚UAでスタイルシートが対応していないじゃないか という話になるのなら実装の話はすれ違い と
>>599 スタイルシートで(その方法は)ご自由に。(例えば)content。
>blockquoteの引用元もstylesheetの役割 初めて聞いた。
titleとciteをcontentで生成 やっぱり過去スレ
>>600 ちょっと上にあるが、contentの書き出しを補助ではなく装飾と考える人も結構いる。
装飾である人にとっては、そんなものでの書き出しは補助ですらないから意味がない、
そもそもCSSで書き出そうとも思わない程度の内容だという事になってしまう。
しかしそうではないから、JSでHTMLをいじる。
それを「stylesheetの役割」と捉える前提からして違うんじゃ話にならない。
>>603 それは装飾だと思う人の手段の一つであって、役割とは別。
>>601 「表現方法はご自由に」であって、引用の明示はUAレベルで義務づけられてるから
「引用の明示暗示自体をご自由に」ではない。
>>604 あれよくわからなかったんだが、
CSSがHTMLいじりじゃなくてJSがHTMLいじりって言う人は、
何がどう違うんだろう?
>>604 HTML上でblockquote要素とcite要素を明示的に結びつける手法は
ないから、そういう意図としてはcite属性で設定してCSSで書き出せ、
という話だろ。
明示とまでいかんでも構造化しておきたいなーという奴はdivで括るし、
そもそも文脈で分かればいいという人は、本文に引用元を書いてcite要素とする。
> それを「stylesheetの役割」と捉える前提からして違うんじゃ話にならない。
その「stylesheetの役割」ってのは、
> なんてのは引用のダブルクォーテーションと似たような位置づけ。
ってのを受けてだろ?
当人がそういうんだからしょうがない。
Javascriptで書き出そうがソースに書いてあろうがHTMLとして意味上の差異はないし、
contentの書き出しを装飾と思おうが補助と思おうが、CSSとしては区別されない。
そういう思い込みや宗教で勝手に意味づけするのはスレ違いだと思うよ。
つーかcontentで生成したtitle属性ってciteもなしのプレーンテキスト?
たとえば直書きで出典元を
>>589 のように書く人が、
citeでの意味づけなしにするような感じになると思うんだけど、
それってCSS書き出し派としてはOKなの?
>>608 書いてる間に・・・・。
>Javascriptで書き出そうがソースに書いてあろうがHTMLとして意味上の差異はない
これホント?
JSで書き出したソースのValidは義務付けられてるけど、
CSS書き出しってValidもクソもない、HTMLとしては無関係のものだと思うんだけど。
>>604 その「ちょっと上」で色々言ってた片方だけど、装飾って言葉は御幣があったかもしれない。
別にcontentで書き出したものは飾りだから何の補助にもならないとは思わないよ。
実際、目に見えて役に立つわけだし、それを否定する人は少ないんじゃない?
CSSで何を装飾するかって言うとHTMLの意味をだと思うわけ。
例えばemを強調として伝えたいから太字にするとか、qを引用として伝えたいから「」をつけるとか、
divで括ったセクションを伝えたいから背景色を変えてみるとか。
そしてblockquoteは引用であることを伝えると同時に
cite属性で示された引用元を伝える「装飾」をするのもありかと。
HTMLで表された意味を伝えると言うことにおいて
colorだろうがcontentだろうが同じだと自分は考えている。
>>607 CSSは、上記の通り。本質的にHTMLを変えるものじゃないという認識。
JSは、実際にドキュメントツリーを書き換えるもの。
HTMLの仕様でもscriptでの書き換え後も仕様に適合するようにとかあったはず。
>HTMLの意味とかそういうところとは離れて、 >要素やらなにやらに対して表示のされ方を指定するものだから。 なんだったら、 >HTMLとして意味上の差異はない JSでの書き出しと、HTMLとは離れたCSSでの表示は やっぱり別物って読めるんだけど。
>>614 > JSでの書き出しと、HTMLとは離れたCSSでの表示は
> やっぱり別物って読めるんだけど。
別物だろ。
誰と勘違いしてるのか知らんが、俺がHTML上での意味が
同じだといってるのは、Javascriptによる書き出しと、
もともとソースに書いてあるのと、だぞ。
blockquoteの各属性に書くのは何がよくないの?
スクリプトで書き出したHTMLのマークアップは 直接書かれているHTMLのマークアップと何が違うの?
1.HTML本文=JS書き出し⇔CSS書き出し(仕様的な観点から) 2.HTML本文>JS書き出し=CSS書き出し(ソースとそれ以外の装飾という観点から) 3.HTML本文>JS書き出し>CSS書き出し(すべてに別の意味を見出してる) 1.なんだとしたら、JSは補助でなくなる。 2.なんだとしたら、JSもCSSも補助になる。 3.なんだとしたら、自分で好きなレベルを選ぶ。 ってところ?レイヤが違う気がする。
JSでのHTMLの書き出しを地のHTMLではなく何か別のHTMLと考える人も結構いる。 んじゃない?
>>615 別物なんだとしたら、たまたまtitle属性とcite属性を*借りてきて*
*本文として*JSで書き出してる人なんだとしたら、
>blockquoteの引用元もstylesheetの役割
これはおかしいんじゃない。実際本文にciteで書く方法も示されていて、
JSでの書き出しはそれの変化系に過ぎないことになるんだから。
>>619 いると思う。
仕様的な意味での同一か、機能追い出しの意味での別物か。
>>622 だったら本文のciteも表示させる必要がなくなっちゃうから、それは違うんじゃない?
HTML本文≠JS書き出しと考える人は、CGIで書き出したHTML文書をどう思っているんだろう
ttp://www.w3.org/TR/REC-CSS2/generate.html#content のcontentプロパティの例で
> The next rule inserts the text of the HTML "alt" attribute before the image. If the image is not displayed, the reader will still see the "alt" text.
> IMG:before { content: attr(alt) }
とあるけどこれはどう判断すればいいの?
blockquoteのcite属性と同列に考えるものとはまた違う?
属性値の生成は想定しているみたいだけど。
電話を取ったときの「○○という用件 ○○さんから」というメモに近い気がする。
通話記録に残ってるから誰からというのはいらないけど必要、みたいな。
違うか。
>>624 それ以前にXMLという問題。
でも「生成され終わった静的コンテンツ」と「生成するインタプリタ」ってのが問題かと。
コンパイラなら完全別物にならないか?
>>627 いやだから
>引用元を意味するテキスト片
になることになるでしょ、JSで書き出そうとHTMLと同一なら。
またメモか・・・ おつかいメモも以前に例として挙げている人がいたけど、 そんなのと一緒にされてもなあ。
でもリストって要するに段落になる前のメモ書き。
箇条書きはリスト?段落?
断片ばっかりの日記で定義リストを使ってる人が多いのはそういう理由?w
>>626 なんとなくわかる
自分の中では
CGI…変換?済のHTMLが送られてきて、それを表示
JS…変換前のHTMLとJSが送られてきて、それを変換してHTMLとして完成させてから表示
CSS…HTMLが送られてきて、それを表示する際にCSSが割り込む
という感覚なんだけれど。
>>628 >>591 の言っているcite要素の使い方はblockquoteに付随するものではなく
昨日初めて<cite>ドラゴンボール</cite>読んだんだけど
ごくうとか言うやつが<q>クリリンのことかー!</q>って叫んでんの。
みたいな使われ方をするんであって
blockquoteには属性としてciteがあるからそこにcite要素を付随させるんじゃない。
って言ってるんだと思う。
cite要素は別の使われ方があってその使われ方んぼ場合は
>だったら本文のciteも表示させる必要がなくなっちゃう
ことはないんじゃないの?
>>630 リストは同格を明示するためのものだと思っている
一、さば缶を買うときは、水煮に限る。 一、セクハラはされるものではなくするものだ。 一、早起きは三文の得。夜寝ないのはもっと得。 一、飛べない豚はただの豚。 一、徹夜しない加藤はただの加藤。 段落になるメモ書きとしたら段落かそうでないかは何で決まるの?
>>634 だから付随や関連づけはどうでもいいんだけど…。
関連しようがしなかろうが、cite要素としてJSで書き出されたものがHTMLと同一なら、
そして関連関係なくそれが本文と思ってJSで書き出すなら、別物なんだから
それをスタイルシートで書き出すのが役目って言うのはおかしいんじゃないの、と言ってる。
関連付けたい人はCSSでもいいかもしれないけど、
たまたまblockquoteの属性値を借りたから関連あるっぽいように見えるけど、
別に関連に関係なくciteとして引用元を書いた場合なのに、
CSSで、なんて言えないということ。
>>635 段落間って同格じゃないのか?同階層だったら同レベルじゃ?
>>363 さとみさんとことのじたんがやってたね。
>>633 JSって、HTMLが全部表示されてから起動するものだと思ってた
onloadのトリガーってbodyが全部送られてからじゃないの?
だったらCSSと同じ位置づけの別物になっちゃう??
>>637 blockquoteの出典元を
>>552 の「(「●●●」より)」のような感じでどうしても表現したいのなら
スタイルシートで出せばいいんじゃない?
でも本来はそんなかたちで表現する必要はなくBlockquoteの属性に書かれているからそれでいい。
>>589 のようなかたちでcite要素を使っているんなら直接htmlだろうがクライアントサイドスクリプトだろうが
意味のある文章だからこれを消してスタイルシートで書けなんて言わない。
意味のある文だからスクリプトで書き出さず直接書けばいいじゃない。
スタイルシートで表現するほど無意味(装飾?)なものではなく直接書くほど重要でもなく
だからスクリプトで、って
その無意味でもなく重要でもないというものを表現するには
(WCMA仕様などの)スクリプトが必須ってこと?
WCMAじゃなくてECMAです。。。
>意味のある文だからスクリプトで書き出さず直接書けばいいじゃない。 なんで?同一なんだからどっちで書いてもいいんでしょ? 直接書くのとJSに違いがあるから直接の方がいいと思うんだったら どっちかを選ぶ権利が使用者にはあることになるし。 意味ある意味ない関係なく楽をしたいからスクリプトを使う場合があるのは CMSでもJSでも同じだと思うけど。
流れぶった切って質問いいでしょうか。 ナンバー付きリストでリストの各項目に対して文章の説明を付けたいときはどうしますか? DT要素にlist-style-type:decimal;ってやってDDに説明書くようにできればいいんですけど、 これは無理ですし。
これblockquoteとciteだったからあれだけど、
Q.ajaxで全部HTML書き出したけどマークアップはどうしたらいいんですか?
A.適宜マークアップしてください。
って質疑応答であるべきだったんじゃないのか?
JSがHTMLかどうか、装飾なのかそうじゃないのかを論じるんじゃなくて、
「(「●●●」より)」をどんなブロックに入れるのか、だけでよかったと思うんだが・・
それに対する回答って見事にほとんど出てないなwww
で、意味ある文をJSで書き出すことにはJS=HTML派でも反対のようだな。
でも意味ない文だとCSSでやれということだったら、JSの位置づけって何だろうな。
ユーザがJSを切ったら〜って話だと、ユーザがdisplay:noneできるHTMLも同様だしなあ。
CSSで本文書きだしは完全反対で終わったのかな?
だったら
>>633 や
>>618 の3が主流なんだろうか。
>>643 >>1 実装の話は(ry
というかCSSスレの話じゃないのか、display:list-item;を忘れてるだけじゃないか?
まあ俺はcounterでやってるけど、内容による。番号がCSSでいいおまけなら。
>>644 スレ違いすみません。ありがとうございます。
display:list-item;やってませんでした。
646 :
645 :2006/08/18(金) 05:40:13 ID:???
試してみたらナンバリングが盛大におかしなことになりました。 ddのなかのulのliまで密かにカウントしてる。orz
>>646 すまん、あれから俺も試してみた。CSSスレの方に書き込んどくから、読んでくれ。
>>621 ,637
つまるところ何がおかしいかといえば、
> なんてのは引用のダブルクォーテーションと似たような位置づけ。
と言う一方でJavascriptで書き出そうとすることだな。
>618の1以外のように、勝手に脳内で自分に都合のいいルールを
作る場合は、そもそもの仕様との適合性を考えてやらないと、
仕様無視の脳内ルールでしかなくなる。
>>646 書いた。
>>648 引用符がUAレベルでHTMLに規定付けられてる=HTMLと同格。
JS書き出し=JS=HTMLだからHTMLと同格。
になると思うが。
というか
>>618 の1.は
>>621 ,637が反論してた相手の主張っしょ?
HTML本文=JS書き出しなんだとしたら、言う相手を間違えてるぞ。
その相手も
>>608 で相手を「思い込みや宗教で勝手に意味づけ」と言ってるんだから、
そっちの相手と思う存分相手の宗教を否定したらいいじゃないかw
HTML本文=JS書き出しなんだとしたら>HTML本文=JS書き出しじゃないとしたら もうこんがらかってきたw
>>644 > 「(「●●●」より)」をどんなブロックに入れるのか、だけでよかったと思うんだが・・
> それに対する回答って見事にほとんど出てないなwww
どれでもいいとかaddressに入れるのはアホだとか、
いろいろでてるな。
> で、意味ある文をJSで書き出すことにはJS=HTML派でも反対のようだな。
すぐ上の>642くらい見ろよ。
つーか意味が変わらんとさんざん言われてるのに、なにを言ってるんだ。
お前のはJavascriptでわざわざ書き出す理由にならんから素直にソースに書けばいい、
と言われてるだけであって、お前の言うようなこと言ってるのは
640だけか少数のレスだと思うんだが。
実際
> 意味ある意味ない関係なく楽をしたいからスクリプトを使う場合があるのは
とか動的に変更したいとか使う理由はいくらもあるのは自明だろ。
していいかどうかとなるとまた一論争あるんだろうけど。
>>651 >>642 は
>>640 の言葉を受けてのイヤミにしか見えないから賛成派には入れてないだけ。
JavaScriptで書き出す理由なんてのはあるかないかは
もしHTML=JSなんだとしたら、Strictの観点からは全く無関係。
逆に、もし「書き出す理由がHTMLで書くのとは別にある」ってことになるんだとしたら、
JS=HTML派ではなくなる。
>>649 単純な話、
引用符はq要素の前後に書かずにUAが書けという仕様だけど、
引用元はblockquoteやciteの前後に書かずにUAが書けなんて仕様じゃないだろ?
「仕様の話だけするなら話すことなんてない」という状況は
こないっぽいね。
> HTML本文=JS書き出しじゃないとしたら、言う相手を間違えてるぞ。
まず自分が、相手の立場を間違えてると疑わなかったんかい。
それはUAが書けというもの>>>直書きciteという意味か? だから引用符>>>HTML=JSと言いたい? その他は意味が分からん。
>>652 > 逆に、もし「書き出す理由がHTMLで書くのとは別にある」ってことになるんだとしたら、
> JS=HTML派ではなくなる。
んなわけねーだろ。つーか、
「Javascriptで書き出そうがソースに書こうがHTMLとしては意味が同じ」
という話で、どうしてHTML上の意味以外のところでJavascriptを使う
理由があったとして問題になるんだか。
その意味が同じなら、その意味以外のところで理由がなきゃそもそも
その手法の需要が存在しないだろ。
>>654 唐突に大小関係がでてくるお前のレスの意味が分からん。
>>655 このスレの場合で話題となるのはその「意味」の部分だけであって、
手法の違いとしての優位性その他はスレ違いだから語るべきでないって意味だ。
だから意味が同じ→どちらを使おうが同じ
というのみがスレ的に許されると思うんだが。
>>565 その二つの仕様が違ったとしても、今回の何に役立つのかわからん。
659 :
645 :2006/08/18(金) 07:10:22 ID:???
>>657 > だから意味が同じ→どちらを使おうが同じ
> というのみがスレ的に許されると思うんだが。
確かにJavascriptを使う理由についてはスレ違いだし、
どっちにすべきというのも(この場合)スレで語るべきことじゃないな。
話が脱線してる。
>どっちにすべき
これもStrict的にどっちにすべきかという観点があるなら有効だと思うけど、
イコールなら話はなくなってしまうな。
ということで、イコール派はもうちょっと詳しく話をしてくれると嬉しい。
意味が同じっていうのは、どういうソースから?
個人的にはvalidでありさえすればソースのStrict性を保つために
多少の非StrictなJS書き出しで、IEにabbrの認識とかいいと思うんだけど。
だから仕様的な動作が同じだったとしても、意味まで同じか?という疑問はある。
むしろ意味を同じにしてしまうことで逆にStrict性を損ねないか、という観点はないかね。
>>552 の場合も、本文だとStrictを損ねると考えたのだとしたら
(CSSでやるかどうかはさておき)HTMLソース外のJSに追い出すことはStrict的に有効だと思うんだが、
意味が同じなんだとしたら追い出しも無意味と一蹴されるんだろうか。
このスレでは、そういうのは結構許容されてきたと思うんだが。
お前ら、最早自分で何言ってるかをわかってないだろw
( ゚д゚)
div1〜6のセクションdivを採用してる人に質問。 blockquoteの中に見出し構造が出現した場合、 blockquote配下にセクションdivも入れてる? それとも見出しと本文だけ?
言語コードのないセム語をspan xml:langで指定したい場合、どうすればいいんだ?
もっと下位の分類で指定したら
>>666 現代だったらできるだろうけど、大昔の語として(;´д`)
>>668 わざわざありがとう。
ないですだ(;´д`)
iso639-2だかでSemitic(Other)にsemという三文字コードが用意されているけど。 セム語派の言語コードがないものは全部これでいいんじゃないの?よくわからんけど。
>>670 うあ。639に2なんて出てたんだ。
otherとはちょっと違う気もするけどそれにする。どうもありがと。
ところで3文字と2文字コードの違いって何?
文字数
↑ アホ
こんなスレで矢印厨を見るとは。 記念に保存しておこう
こんなスレで保存厨を見るとは。 記念に(ry
こ(ry
↑ スペースが入ってる。文章改変。
結局誰も知らない、と。
ここで聞くようなことか?
見出しごと引用・・・って、章だか節だかを丸ごと引用してるってこと? たとえば章だか節だかの最初の段落だけなどを引用するなら見出しの引用はしないよね。 引用の条件の慣行に沿っているかどうか疑問です。
別に章だか節だかがそんなに長い文章ばかり転がってるもんでもなかろ、特にWebでは。 大体主が自分の分になればいいんだから、 どんな長い文章を引用したって、それ以上に書けばいいだけだしな。 俺はやらないが。
そういえば辞書の引用で、単語を見出し、文章を本文にしてるところがあって、 どうしようか悩んだ結果dl-dt-ddに変えちゃったことがあったような。
単語と単語の意味の引用なら定義リストが普通じゃね?
引用先のマークアップもそのまま引用するのが慣わしなんだ
他人の文章を基本的にはマークアップできないという理屈も知らんのか?
ねこめしでのあたんのリスト日記をpに直してるのを謝ってたね。
慣わし以上でもないけどね。
全部hnでマークアップすればSEOが(ry 引用は相手の意図をそもそも伝えなきゃ意味がないから 習わし以上のものがあるだろ
CSS適用をそろえる必要はないがHTML表現をそろえる必要はある、 というのが慣わしでなく義務だって人の主張だな。 が、文章を引用すればそれで十分文意が伝わる、 という場合がほとんどだろう。もちろん引用元が マークアップまで同一にしろと要求する権利はあるだろうけど、 「著作物の性質並びにその利用の目的及び 態様に照らしやむを得ないと認められる改変」 なら、まあいいんじゃないの? 程度によるだろうけど、実際のところケースバイケースであって、 そういう義務はとくにないと思う。意味もなく改変しなければ 問題が起きにくいよ、という良い習慣のひとつではあろうけど。
公式には特に何も言及していないんでしょうか。マークアップ部分の引用について。 マークアップの部分にclassやidが振られていてバッティングするなどといった場合は、 少なくとも改変しないといけないですよね。せざるを得ないというか。
>>692 ストリクタにとっては義務だと思う。
というかやむを得ぬではない改変だろ、というのは昔議論があったような。
いいえ書き直してはいけません。習わしです。習わし以上のものです。
昔(俺の中で)議論があったような。やむを得ぬではない。 一方その頃、俺の中での議論では、 不思議マークアップやそれのみならず納得のいかないマークアップがあれば 引用そのものを断念しろという結論が出た。
>(俺の中で)議論があった 吹いた。
もし引用でマークアップ改変を*考え無しに*することができる香具師なら 詩はpreだと言い出すこともないだろう。 ところがこのスレはそうではない。 そういうことだ。
じゃあ俺の中であった議論ではどこまで改変してもいいかどこからはだめかという基準は 俺の中の習わしに基づいて判断してもおkという結論が出た。ということにする。
>>693 IDはともかくclassは問題ないだろ
じゃあID被ったらどうするの?
↑ バカ ↑ やってみたかった。
classは一意ではないけど、自分のところで意味づけしているものと違う場合があるんじゃない?
↑ そんなのマークアップ自体だってそうだろう。
さっき詩を引用するためにページのソースを見たんだ。 一行ずつ全部divだった。 泪を流して諦めた。書籍買ってくる・・・
紙媒体からの引用がいいね。
改変すべきではない派もIDの書き換えや削除は容認? IDの改変もどこかのコミュニティでは習わしになってるの?
そういえば、映画やゲームの「声」の引用の場合、 どうしても表記には揺らぎが出ちゃうと思うし、正式な台本なんか手に入るはずもないし、 たとえ正確な引用でない改変が入っちゃっても、仕方ないと割り切ってqで引用していいものだろうか? それとも単に「"」直書きで囲うだけにしておいたほうが無難だろうか。
>>707 IDに関しては「やむを得ぬ改変」であって、どうしようもないだろう。
それ以外は・・・・・・・
「俺様によるテープ起こし」という注意書きを入れておけばいいと思うよ。
やむを得ぬ改変はおk、ってどこのコミュニティでの習わし?俺の中?
つ【法律】
マークアップそのものが止むを得ない。俺の中のマークアップの基準とバッティングする。
やむを得なくないな。
やむを得ないかどうか裁判で争おう
引用元の中の人から文句を言われたら書き直せばいいってことね。わかった。 HTMLとかそっち界隈の話題を扱っていないから突っ掛かって来られることもないと思うわ。
↑ 全然解ってないバカ
このスレでも目の前の箱を利用できない人がいるの?
マークアップの見えない部分も引用元に従わないといけないって考えの人は 参照元を示すのはblockquote要素の属性値だけでいいって考えも併せ持っていますよね? 漏れもそうです。
それってごく普通の行為だとは思うが、 それよりその二つの間に関連性はないと思う。
マークアップを引用してるつもりの人は改変しちゃ駄目で、 文章を引用してるつもりの人はマークアップが異なってもOK。 ただ後者は、マークアップによる意味づけが引用に際して 欠落することに注意する必要がある。とくに同等の マークアップが特に障害なく可能な場合は、妥当な改変 とはみなされないだろうな。 まあ、現実的には裁判に行く前に解決できる必要があるから、 ボーダーケースな場合は引用元にお伺いをたてたりとか、 そういうトラブルの事前事後回避策を講じる用意をする必要が あるだろうな。 Strict的には、明らかに不正なマークアップでない限りは、 引用元の意図を尊重してマークアップをママにしておく のが正しいだろう。 「この不思議マークアップは引用元ママです」とソースに コメント書いておけばOK。
不思議マークアップは「引用しない」が一番だとオモ。
> とくに同等の > マークアップが特に (原文ママ)
>>664 がWebの引用だったら論じるべくもないが、
本だったら・・・・冗長だけど揺らぎをなくすために入れた方がよさそげ。
機種依存文字の入った不思議文章だったら 改変しても「やむを得ない」に入るだろうか・・・
>>727 係り方は、
とくに→可能な
特に→障害なく
ですよ。
>>732 注釈いれればOKだと思う。
「やむを得ない」は物理的に不可能なことであって、注釈の有無とは関係ない。
> 「やむを得ない」は物理的に不可能なことであって 脳内定義乙 「その他の利用の目的及び態様に照らし、やむを得ないと認められる改変」 は認められるから、注釈付で改変するのはまーOKじゃない? というかそもそもスレ違いじゃない?よく考えたらHTML関係なくね?
もう引用の部分だけSSとって貼っちゃおうぜ!
それはそれで、代替テキストをどうするのよ
テキストだから文章だけ書けばいいんじゃね?
>>735 そっちのが脳内定義だが。
注釈があろうとなかろうと、「やむを得ない」には物理的に近くその方法では絶対に無理
というかなり限定された理由がないと改変は認められない。
別にマークアップ自体を引用している訳では無いだろう。 重要なのは文章・文脈であり、 それを己のマークアップルールに咀嚼するのが、Strictだと思うが。 例えば、 紙面であっても、見出しと本文を視覚的に分かる様にしているが、 ”引用における見出し”と”己の見出し”とを、視覚的に同じにはしてないだろ。 と言うより、その点を強調したいなら一文入れて それでもって、見出し云々を指摘すると思うがな。 マークアップ自体を引用するならば、 blockquoteにpreにソース、だと俺は思っとる。
ソースに著作権はないんじゃかったっけ?
>>740 マークアップを変えるということは、
相手の文意を無視して自分の信念で「文章の意味を変える」行為。
そんなことが許されるならば、詩だろうが掲示板コメントだろうが
「preで」なんて話は出ない。
相手の文意をこちらが勝手にマークアップできないからこそ
「整形文」なんて飛び技を使わざるを得ないのに。
>>740 視覚的って・・・
プレゼンテーションの話はスレ違い。
>マークアップ自体を引用するならば、
>blockquoteにpreにソース、だと俺は思っとる。
スマン、blockquoteにpreにcodeにソース、だ。
>>741 マークアップの方法そのものを引用したいから、”ソース”と言ってみた。
御指摘のように、マークアップの方法つまりはソースそのものには著作権は無いよ。
>>743 うーん...あんまり意味が通じてないか...
例えば、
紙面で、見出しをも引用したとすると、
引用された見出しは、己の見出しと同じ様に表現されているのか?
(同じ書体で、同じ大きさで、同じ太さで表現されているのか?)
違う筈だ。見出しであっても”引用”であると分かる視覚的な方法で示しいるはずだ。
だったら、マークアップにおいても同じだ。
同じ要素を使うならば、それは全く同じ使い方でなくてはならない。
>>742 >マークアップを変えるということは、
>相手の文意を無視して自分の信念で「文章の意味を変える」行為。
俺はそこまで深くは考えないし、
それにソースを直に見れば、大方その人の文意は理解している積りだ。
ご存知の通り、HTMLに用意されている要素、又その意義は少ないから、
ソースを見れば大体分かるんじゃないか?
>>742 横槍ですが
> 詩だろうが掲示板コメントだろうが
> 「preで」なんて話は出ない。
これしちゃダメなんですか?
>>746 逆。preでなくてもいいこっちで勝手にマークアップしていい、
って言ってるのが
>>740 。
>>745 その文意がとんでもないマークアッ府なことも多々ある件。
ていうかそこまで考えない香具師がこりスレにいる意味はないんじゃね?
あれ、引用部分をとってきて、その中の特定の部分を <strong> とかってやったりしないの?
引用部分はそれだけて「他と区別できるよう」レンダリングされてなきゃならないから、 すでにstrong扱いだと思うのは俺だけか。
例えば、人類が滅んで、 二千年後、遺された物がHTMLとするじゃん(有り得んけど)。 その遺されたHTMLから、 文字が在ったんじゃと想定し、 その同一性を吟味して、 <>に挟まれている印は、何か意味があるんじゃないと思う。 しかも、その挟まれている文字らしき物に似たような物があり、 その種類は数種類に限られる。 title、これは文章上に位置して今後出てこないから、 これは「主題」なのか.... hが付いて1〜6の文字が所々にあるが、 何故か1~6っぽい文字は階層的に出現している.... blockquote、数々の文献に似たような文字が見られるので、 これは、その引用文という意味か.... 現代人でも、古文書が出て来たら、そんな事は推測するし、 なるべく認知できるようにできるように、 考えてやれるには人間だけ。
> 文字が在ったんじゃと想定し、 わかった!その想定している人は老人ですね!
>>752-753 いやいや、オマイラは笑うかも知れんが、
俺はその積りでHTMLを発信している。
己の信条に従ってマークアップしていし、
他人が見たって理解できんようなアークアップはしとらん。
俺のHTMLを100ページ見れば、
おそらく宇宙人も”マークアップだけ”は理解できると思うぞ。
>>754 そうしておまえの信念に合わせて他人の意図が変わってしまった文章が宇宙人に誤解されるわけだな。
>己の信条に従ってマークアップしていし 引用をコレすることが問題だというに。
流れぶったぎってごめんなんだけど、 <link rel="parent" /> って書くと親になるよね。 親の親を示したいときは <link rel="parent parent" /> でいいのかな? やっぱ無理?w
>>756 >>己の信条に従ってマークアップしていし
>引用をコレすることが問題だというに。
分からん。
なぜ、引用部分を、己のマークアップに従っては駄目なんだ?
改変した何ぞやを「引用」として「引用元」に責任押し付けかねないから
>>759 なら、書物やその他のメディアからの引用はどうするんだ?
例えば、書物においての”強調”は、
斜体文字であったり、太字であったりする。
その部分を引用する時、その部分の意味を織り込みながら
己自身のマークアップするんじゃないのか?
>>760 親 : ../
親の親 : ../../
みたいなw
>>761 誰が他メディアの話をしてるよ。
他メディアはマークアップが存在しないのだから、推測でしかマークアップできないのは「仕方なく」だろ。
でも書物でも傍点をemに、太字をstrongにすることは
書物のマークアップに則って相手のマークアップに合わせている、という言い方も出来るが。
>>763 「仕方なく」では無い。
マークアップにしろ、他のメディアにしろ、
まずは、その文脈・意味をを知る事だ。
書物において傍点が”強調”とは限らんし、
太字が”より強調”と限らん。
そもそも和書と洋書とじゃ、その意味合いが違う。
ふと思ったんだが、君は、
b要素を”強調”の意味で使っているマークアップ文章を見付けた時、
どのようにマークアップ引用しているんだ?
>>764 言っとくがおまえの意見を否定してるのは俺だけじゃないから、
君という呼びかけは無意味だ。
文脈・意味を「理解した」つもりがとんでもなくずれてるなんてことはままあることだし、
今まで散々ポエムはpreという結論が出てきたのも何のためだと思っているんだ。
そしておまえの言うとおり太字の意味が違う可能性もあるかせ、
そういうのは「いじってはならない」と言っているんだ。
b要素なんて使ってる文章はそもそも引用できない。
そこまで自信たっぷりなマークアップをぜひ見てみたいもんだなあ
>>764 意味合いが違うからこそ、マークアップされている文書はマークアップされたまま引用する。
そうでないものは整形済みとして扱うか、そうでないなら最大公約数足りえる補完を行う。
ただしその場合、お前のように「己の信条に従ってマークアップ」なんてことはノイズでしかない。
結論が出たらまとめてね
>>739 いや、「物理的に近く」なんて意味不明瞭な限定はないでしょ?
法の文面をより詳しく解釈する判例とかあるならそっちの文を
引用した上でこっちの解釈が不適だと言えば済む話であって、
脳内言語で脳内定義を語られても意味分からんよ。
基準が緩くないのは知ってるけどさ。
基本的にはマークアップもそのまま。 変えたかったら引用元に連絡し、許可を得る。 それも無理なら諦める。 俺はこうするよ。
>>765 >b要素なんて使ってる文章はそもそも引用できない。
b要素使えばいいんじゃないの?
>>768 >意味合いが違うからこそ、マークアップされている文書はマークアップされたまま引用する。
これって突き詰めると違う仕様を使った文書は引用できないってことにならない?
マークアップだけ書き写しても、引用元の意図を反映しているとは言いがたいと思うんだけど。
自分自身は、引用するような文章って普段書くことが無いんで
あまり考えたことは無いんだけど、なんか違和感を感じるなぁ。
特に物理マークアップな文書は引用できないって言う考え方が納得出来ない。
DTD上、扱えない要素や構造があった場合も引用不能?
>b要素使えばいいんじゃないの? >DTD上、扱えない要素や構造があった場合も引用不能? ?!(゚д゚)ポカーン
表示されてるテキストだけコピペって勝手にマークアップすればいい話なのにね。 マークアップ次第で引用不可とかワケワカラン
なんかストリクタじゃないのが紛れ込んでるな。
違う仕様って何のこと?
引用元との同一性を保つと言っても、 文の意味が同じ → 文が一字一句が同じ → 要素のマーク付けまで同じ → ソースのインデントまで同じ → 文字コードまで同じ → … と考えだすと切りがない。だいたい、そこまで同一性を保たねばならない のなら、「引用」などせずに「リンク」にすればいいんだ。「引用」である 以上、絶対に同一性はどこかで崩れる。
>>772 最初に出た「blockquoteの中に見出し」なんて、
そもそもISO-HTMLでは「物理的にできない」な。
ではどうするかといえば、大抵は「見出しは引用しないことにする」か、
「ISO-HTMLではないDTDでマークアップする」かどちらかになる。
これは*引用不能*と言わないのなら、何と言う気なんだ?
>>777 その何処かのレベルをできるだけ引き上げようという努力は
しなくてはならないというのが法律上の決まり。
インデントも「インデントに意味がある」詩のような場合と
「インデントに意味がない」ソースだけの場合だと
「スレ的に」意味が違ってくる。
多分法律上もそこは問題にするだろう。
blockquoteの中ではhtml xhtml iso-htmlの混在が可能ってこと?
・・・・・・・・・・・・なんか本当に妙なのが紛れ込んでいるのか? それともボケるべき?
| ̄ ̄ ̄ ̄ ̄ ̄| | 次でボケて!! | |______| ∧∧ ‖ (゚д゚)‖ / づΦ
>>773 何かおかしい?
マークアップをそのままにしろって言う主張の場合、
b要素がDTD上使用不可でないかぎりb要素を使うべきなんじゃないの?
なんで他は同じマークアップにするのにb要素は駄目?
その辺に一貫性が感じられないって言いたいんだけど。
>>776 同じHTMLでもバージョンが違うものとか、ISOとW3Cとか。
>>778 マークアップのせいで引用できなくなるなんて変じゃない?
他のメディアからの引用は誰も否定しないのに
HTMLからの引用となると、ものによっては引用出来ないなんて違和感がある。
>>780 誰もそうは言ってないよ。
煽り文を思いついた 「君は引用元のHTML文書(の一部)が君のHTML文書に最適化された マークアップじゃないと引用も満足に出来ないの?」
引用元の人の意に反した改変を加えるのは禁止なんだから、 やむをえない改変かどうか判断に迷うような改変を加えなきゃ いけない状況なら、引用はできないことになるだろうなあ。 ある人のStrict的基準では「マークアップ変えなきゃならんなら 引用するな、不思議マークアップも同じ」というものになるようだけど、 「どんなことが改変にあたるか」というのは基準があるのかな。 ただ、その、法解釈上の基準についてはここで話すことじゃなかろう。 Strictスレ的には、 ・マークアップを変えなければ大丈夫。 ・ソース上のインデント変更なんかはHTML上の意味が変わらないなら大丈夫。 ・それ以外がだめか否かはこのスレで分かる範疇じゃない というところなんじゃないのかな。
「連続する空白は単一の空白と同じ」というのはHTML/XHTMLのルールで あってSGML/XMLのルールではない。つまり、混合内容部分のソース上の インデントを変えたものは、HTML/XHTML的には同じだが、SGML/XML的 には異なる。 同一タグ内の属性(例えばaltとsrc)の順序を入れ替えてもSGML/XML的には 同じだが、テキストとしては異なる。 文字コードが異なれば、テキストとして同じでもデータとして異なる。 このように、同一性なんてものは、どのレベルで話をするかで全く判断が 違うもの。「SGML/XML的には異なっても良いがHTML/XHTML的には同一で なければならない」なんていう主張は、結局は俺判断でしかないでしょ。
その「どのレベルか」も相手に合わせられるなら問題のないこと。
結局、基準は人それぞれってことで。
↑ 全然読んでないだろ。
(俺様の脳内基準の書き込みを)全然読んでないだろ。
>>785 「著者の意に反した改変は禁止」を拡大解釈してないかな?
じゃあ、著者がデータレベルでの同一性をを要求していたら、引用時には
文字コードまで同じにしなきゃならない?
長い段落を引用する際に、著者が、800x600 の Win-IE5.5 の文字サイズ小の
環境での改行位置の同一性を要求していたら、引用時はそれに合わせてないと
ならない?
しかし、引用は著作権法上認められた権利な訳だから、著者が要求を厳しく
することで事実上引用不可能にしてしまうことはおかしいと思われる。
「どのレベルまで同一であるべきか」なんてことは著者の要求によって決まる
のではなく、「一般社会通念上の同一性」で決まるんじゃないのか?
だとすると、文字の一字一句の同一性は必要だが、マークアップの同一性は
必要ないと思えるが。
引用時の装飾やマークアップは関係ないだろ 変えたらダメってんなら引用自体できなくなる 引用文を強調したあとで、 (強調は著者によるものである) なんてのも出版物でも普通にある
出版物にはマークアップがないから参考にならないな。
マークアップはなくても装飾はある よく嫁
>>786 > 「SGML/XML的には異なっても良いがHTML/XHTML的には同一で
> なければならない」なんていう主張は、結局は俺判断でしかないでしょ。
いや、Strict-HTMLスレでHTMLにおいて意味の同一性を保つという基準
は"俺判断"とまで狭くはないだろ。Strict-HTMLスレ基準ってのが狭いっ
てのはその通りだけどな。
>>791 > 「どのレベルまで同一であるべきか」なんてことは著者の要求によって決まる
> のではなく、「一般社会通念上の同一性」で決まるんじゃないのか?
俺は
> 「どんなことが改変にあたるか」というのは基準があるのかな。
> ただ、その、法解釈上の基準についてはここで話すことじゃなかろう。
と書いたんだが読んだ?
>>794 装飾はマークアップと切り離して考えないと。
いや、引用に関しては似たようなもんだって なんたら<strong>かんたら</strong>どうたら ってなのは問題ない これが出版物だと太字とかにされてるのとか普通にあるしね もちろん改行の位置などが変えられることもしばしば 心配なら、注意書きをしておけばベター
>>765 >b要素なんて使ってる文章はそもそも引用できない。
何で、b要素を使っている文章は引用できないんだ?
>>765 の主張が仮に正しいとすれば、当然
書籍の文章の装飾はどういう意味かわからないから
書籍からはそもそも引用できないという結論になるんだよね
>>795 b要素をマークアップできるDTDで書いてない場合、不可能という言葉以外にはないだろう。
なんでそんなにマークアップ丸ごと引用したがるの?(´・ω・`)
なんでそんなに他人の意図を無視したがるの?(´・ω・`)
(´・ω・`)----*----(´・ω・`)
”マークアップそのまんま派”は、
具体的に、
>>664 にどんなアドバイスを示すわけなの?
何ていうか、あれだ、引用する側の脳内ブラウザの仕様に準じればいいんだよ。 だいたい、引用するなら必ず引用元のソースを覗かなきゃいけないなんてことはないはず。 ・向こうが <ul> とか <ol> とか使ってれば、それは 「リスト」 だと判別できるからそのまま使う。 ・<h*> とかは 「見出し」 だとは認識できるけど、見出しの 「レベル」 なんかは認識できないのでレベルを保持する必要はない。 ・<b> とかは <font size> とかはうちの脳内ブラウザでは 「強調」 だと認識したので em なり strong なりに変える。 ・<div class="hoge"> とか インデント なんかは見てる分には認識できないので基本的に放置、もし認識・推測できたら好きにする。 いいじゃんこれで(´・ω・`)
そうして意図を無視した脳内仕様で改変され続けた伝言ゲームのような有様に。 確か「世界に100人しかいなかったら」がそんな感じじゃなかったっけ。
808 :
804 :2006/08/25(金) 12:14:21 ID:???
>>664 否定派の俺から意見。
是非ならば、見出しは引用するな。
しないような文章を書くのが一番であり、
どうしても引用するならh1〜h6要素を使わず、
自分の納得いくマークアップを施せ。
h1〜h6要素から成る見出し要素は、
あくまでも、その文書自身の見出しであって、
引用先のそれを示す事は出来ない。
その文書自身以外の見出し要素が存在することは、
想定されていないし、WWW運用上においても害にしかならない。
それ以前に否定派、肯定派の概念が違う気がした。
objectで別htmlを埋め込めばDTDは解決。
だから、そこまで同一性を保持したかったら、引用せずにリンクしろって。
だから引用しないという意見は何度も出ているではないか。
引用しないということに納得しないバカがいるからな。
引用って、引用しなければ文章が成り立たないとか 引用することに「必然性」がある場合にのみ(無料で)できるんでしょ? 引用しないでも済むということは、 その引用自体ルールから外れてるんじゃないか? その文章自体書くなということか。
対Webの引用には、そもそもリンクという概念があるのだから、 引用の必然性を言うと、そもそもが薄いよ。 でもリンク禁止だとか言う馬鹿には引用は法律で認められていますという手が使える。
本と違ってちょっと突っ込まれるとすぐ消す香具師もいるからな。 馬鹿相手だと引用の必然性があるってのも馬鹿げた話だ。
馬鹿相手でなくても、参照先のURLが永続的に有効だと
保証されてるわけじゃないので、自分の作成した文書と
参照したい文書(の引用部)の寿命を一致させるためには、
引用は有効だと思う。
ハイパーリンクの有効でない環境に文書を写す(移す?)
際にも有用だしね。
>>800 なんで俺?
>>804 > div1〜6のセクションdivを採用してる人
が少なかった(1人?)ということじゃなかろうか。
>>815 リンクも法的に問題ないでしょ。
むしろ、そういう馬鹿は引用に対し「無断転載しないでください!」とか言い出すんじゃ。
行政だったかどこかがリンク電話許可性にして話題を呼んだことがなかったっけかww 違反したら法的手段とか何とか。
リンク電話って? 「こちらの行政機関のお問い合わせ電話番号は00000000です。」とか? 「みなさん電凸しましょう。」とか書いてたりしなくても禁止?
>電凸 これ何?
電話突撃もよくわからない単語だな。
そそらくはもっとよくわからない単語だな。
リンク電話許可性って何?
"電凸" の検索結果 約 211,000 件中 1 - 10 件目 "電話突撃" の検索結果 約 53,500 件中 1 - 10 件目 "リンク電話" の検索結果 約 519 件中 1 - 10 件目 "電話許可性"に該当するページが見つかりませんでした。 "リンク電話許可性"に該当するページが見つかりませんでした。 "そそらく" の検索結果 約 284 件中 1 - 10 件目
「そそらく」あるのか!
そんまし!
リンク電話許可制って何? 当サイトへのリンクは電話にてご連絡ください。その上で許可するかしないかを判断してやる。 ってこと? というか「許可"性"」?
性は誤字だwww リンク電話許可制ってのは内容から俺が勝手に言ったものだが、 要するに「リンクする際は連絡を」の連絡先が電話番号だった、って奴。 当時は面白がって電話した奴がレポートをあちこちに上げたものだったが、 詳細は覚えてない。
HTML5ってどうなったの?
>>832 それじゃない、もっと昔の。
そんなのもあるのかww
そういえば今現在、本気でHTML5を作ろうとしてる連中がいるね。 そこまで否定するような物かな。XHTMLって。
body に dir="ltr" を指定している人に質問なのですが、 あえて dir="ltr" であることを明示することに どのような意味があるのかを教えてください。 けちをつけているのではなく、単純に興味があります。
body 要素ではなく、html 要素でした。
同要素のlang属性にja-JPだのenだの書くのと同じ程度の意味。
xml:lang="ja-2ch" とすれば2ch語。
mjdk
ja = Japanese = 日本語 JP = Japan = 日本(国) ja-2ch = 日本語2ch(国)
ん?
ja-JPを「日本国で使用されている日本語」とすれば ja-2chは「2chで使用されている日本語」=2ch語 ならないか
言語コードの副タグは2文字だと国名とみなされ、3文字以上なら適当に決めてよいことになってる 詳しくは RFC3066
>>844 文法は
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
だしよさげ?
あらゆる言語と多彩な絵文字を包括しているunicode以上の言語かも
847 :
Name_Not_Found :2006/09/03(日) 10:04:30 ID:+8Fm837+
<dl> <dt>名前</dt> <dd>田中太郎</dd> <dt>趣味</dt> <dd>読書、映画鑑賞、インターネット利用、スキー、登山</dd> </dl> は、 <dl> <dt>名前</dt> <dd>田中太郎</dd> <dt>趣味</dt> <dd> <ul> <li>読書</li><li>映画鑑賞</li><li>インターネット利用</li><li>スキー</li><li>登山</li><li> </ul> </dd> </dl> のほうがいいですか?
<dl> <dt>名前</dt> <dd>田中太郎</dd> <dt>趣味</dt> <dd>読書</dd> <dd>映画鑑賞</dd> <dd>インターネット利用</dd> <dd>スキー</dd> <dd>登山</dd> </dl> これが候補に挙がらなかった理由を教えて。
<strong>と<em>の違いって何? ブラウザでの見え方の違いとかじゃなくて意味に差はあるの? 例えば<strong>の方が強調の度合いが強いとか。
850 :
836 :2006/09/03(日) 12:14:34 ID:???
どうもありがとうございます。参考になりました。 >838 わかりやすい例ですね。
851 :
Name_Not_Found :2006/09/03(日) 12:32:40 ID:zuTH2G63
>>849 >例えば<strong>の方が強調の度合いが強いとか。
まったくそのとおり
XHTML2.0はstrongだけになってstrongの入れ子で強度を表現するようになる んじゃなかったっけ?
まだ勧告されていないものをなぜうろ覚えで確認しますか。
>>853 取敢えず、最新のWDでは両方(em/strong)とも残っている。
em って「強調」っていうか「変調」って感じで使ってるわー。 会話で言えばアクセントつける感じ。 strongは声でかくしてゆっくりしゃべる感じ。 統合されたらちょっと困るw
emとstrongの使い分けが出来ていない。 つか、そもそもstrongじゃなくてemの入れ子でいいじゃんと思ってしまう。
物理マークアップおめ。
859 :
Name_Not_Found :2006/09/03(日) 19:16:50 ID:siea+WDD
>>847 プロフィールのようなものは、tableが最適だろ。
860 :
Name_Not_Found :2006/09/03(日) 21:06:22 ID:KRRlHz++
inputと共に使うのは、label・forとdt・ddのどちらがいい?
どっちがいいとか、その選択肢がようわからんなw
なんでどちらか選ばないといけないの? labelを使ったらdt/ddやpやtableやその他、 そういうのを使っちゃだめってわけでもないし。
>>857 確かにstrongって長いから面倒。
emマンセー
emはいちいちCSSでイタリックじゃない指定をするのがだるい。 日本語は斜体には向いてないんだよ。見難くくてかなわん。 それに入力補完マクロ使ってるからstまで打てばいいし全然苦にならん。
>>864 まずブラウザのデフォスタイルを打ち消すのが普通かと思ってたけど、そうでもないのね。
まあそもそもスレ違い。
論点が「斜体」と「太字」なら、 そういう意見もあるな。
メイリオだと日本語は斜体にならないし VistaのIEはデフォルトスタイルが変更される…わけないか
>>865 最初にmarginとpaddingは消すけど、
使わないemのイタリック指定なんかいちいち消す必要ないからね。
それにそもそもemがデフォルトでイタリックなのは、
向こうの文化で強調にイタリックを使用するからであって、
日本には当てはまらないしな。
日本語では「」『』みたいな括弧とかが近いだろうから、
CSSで前後に括弧を指定とかした方がベストに近そうな気がするけど。
ただ、太字より「」の方が強調は強そうに感じるのがネック・・・w
>>867 見た目を分離は所詮後付けの仕様でしかないし、
要素のベースになったものが斜体にする文化とかだろうから、
それ程見当違いには思えないな。
>>870 スレ違いの話題を引っ張るのもアレだが、
「使わないemのイタリック指定なんかいちいち消す必要ない」なら、
「emはいちいちCSSでイタリックじゃない指定をするのがだるい」とかどうだっていんじゃないの?
そもそも最初に em { font-style: normal } を書くだけがそんなにだるいんか?
私は最初に、全ての要素に対してスタイルを定義(すなわちデフォルトのスタイル情報を殺す)します。 その後、classesなどで細かい指定をします。 さらにページでスタイルの変化が欲しい場合には、link要素で別に用意したCSSファイルに リンクします。 最初は面倒だと思うかも知れないが、慣れるとなんともないよ。きっと。
873 :
Name_Not_Found :2006/09/05(火) 11:16:53 ID:ta+AuNkM
質問なのですが、 window.openで別窓を出してその別窓を 閉じない限りリンク元のページを操作できなくする方法って どうやるのでしょうか?
スレ違いです。 この板のスレッド一覧を「初心者」で検索して、 そこの人に聞いてください。 適切な場所に誘導してもらえるでしょう。
875 :
Name_Not_Found :2006/09/05(火) 11:38:26 ID:ta+AuNkM
すみませんでした↓
new 商品名 発売日 詳細 みたいな物があった場合どんなマークアップをしますか? 一応ページのメインに近い内容なので商品名だけhnであとはpなのですが dlとかの方が良いのかな?と思ったもので よろしければ意見を聞かせてください。 ちなみにnewと発売日は結構小さい表示でおまけくらいな感じです。
背景がきもかった
ins・delって文を修正するたびに使ってたらins・delの嵐になりませんか? この前insしたものを今回それをdelする・・・とか。 ins・delを使ってどこを個別に加筆修正したかというのを示すんじゃなく ページ全体を編集したことにして、 そのページの上や下に「最終更新日」というのを入れたほうがいいんでしょうか。
そんなに修正する文書って何の文書だよwww 長いのだったら <ins>以下 ’06/09/06 追記</ins> <p>だらだら</p> <p>だらだら</p> でいくね?
web上には思いつきで書いた書きっぱなしのブログ類か ローカルで熟考を重ねた上で公開された文書類しかないので del insはそれほど使われることがない。
ていうか今の今までそんな存在感の薄い要素忘れてたわ
883 :
Name_Not_Found :2006/09/06(水) 20:25:11 ID:jP4oVPqW
一つのURLをクリックすると、 二つのウィンドウを開くことはできますか?
なんでこのスレで聞こうと思ったの?
<ins>Java</ins>S<del>t</del><ins>c</ins>rict-HTMLスレッドだからさ
後ろのcはpにしないんだ
失敗しちゃった><
JavaStcrict-HTML
889 :
Name_Not_Found :2006/09/08(金) 05:24:56 ID:cV5Cf3dE
そんな誰でも知ってることを最近知ったの?可哀想なやつ
神崎たんは凄いと思うけどいまいちストリクタではないと思うんだ。
自分も初めて知った。 まだまだWEB界の常識には疎いわ。
つーかこのスレでも何度も名前が出てる人じゃないか。
いや、書籍の存在を知らなかったんだ。
そもそも、ストリクタからの支持は異常といえるぐらいすごいが、 一般的には無名に近くない?w
つ 答え 君がまだそのくらいのレベルだから
ふざけんな、俺の大学にお勤めだぞ。 知らないとは言わせん。
とほほの方が有名だよ
とほほは本当にとほほということで有名ですね確かに
俺の周辺ではみんな、教えてと言われたら まず神崎氏の30分で〜をすすめてるよ。
他の板やスレで聞いたら全く違う回答がくるに300000カノッサ。
初心者って「色変えたい」とか「文字大きくしたい」とかの欲求が強いんだよな。 だから神崎氏のページは全くの初心者にとって微妙な気がする…と最近思い始めている。
ホームページビルダー買え でいいんじゃない?
昔チンコパッド買ったらついてきたな > ビルダ
C言語のソースとかはlang="art"とするべきだが、 HTMLで日本語の文章をマークアップした例とかは如何扱うべきだと思う?
釣り?
マークアップした時点で自然言語をマークアップ言語が包むんだから 人工言語としていいんじゃないかな
>>909 結局、code要素にlang="art"を付けました。
何故かlang属性を書かない人って多いよね。abbr要素とか。
<abbr title="HyperText Markup Language" lang="en">HTML</abbr>
>>910 人口諸語=プログラミング言語とするなら、
そもそもcode自身が表す要素じゃね?
>>910 考えすぎじゃね?
「HTML」 だって日本語っちゃあ日本語なんだし。
・・・・・「えいちてぃーえむえる」ならそう認めてもいい。
>考えすぎじゃね? li/dd要素の内容が段落である場合にp要素でマークアップしないと気持ち悪いのは重傷かなぁ
>>915 重傷でもないというか、それ以外にどうやってマークアップする気だ?
>>916 li要素直下にp要素を使っている人は殆ど居ない様な気がするのだけど。
>>917 小説の意味段落をol-liでやってた奴を見たことがある。
当然そいつのliの下にはpが大量に存在していた。
リスト厨ってどこからが始まりだろうと悩んだ。
概念が分かりやすい割にhn-sectionすら包括しちゃいそうなくらい定義が曖昧なんだよな。
dl-dt-ddも以前hn-pとの区別がつかないままこでFAしてなかったか。
>>910 は 「J-POPアーティスト」 とかをどうマークアップするんだろう。
>>921 いや、これは永遠の謎だって。
結局、本人の意思と言いたいが、
受け手の自由でもあるんだな。
たとえば、
baseballと野球は、
翻訳上は同じでも、実質は違うと言う人は多いと思うよ。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・はい?
「ベースボール」は日本語表記だが英語、とか、そういうことか?
Tabletennisと卓球みたいなもんか。
「ジスイズアペン」は英語で「kore-ha pen desu」は日本語というように、 書かれている文字種には依存しないという話もあるな。
そもそも何が「日本語」なのか。ひらがな+カタカナ+漢字(+和字)表記か、 日本文化圏で使われる「単語」(表記方法問わない)がそうなのか、両方か。
lang属性は自然言語が何かを表すのであって、プログラミング言語とかは 表さないってどこかで見たような?どこだったか思い出せない。 msg = "hello"; みたいなのは <code>msg = "<span lang="en">hello</span>";</code> で良いと思うけど。
>>928 そこまで分けるのか?
この場合、プログラミング言語としての”hello"が重要であって、
別に、msg=”こんちわ”、または、msg="你好"であっても良い筈だ。
ここに固有の意味合いや、字その物の意味情報を入れても意味が無いと思う。
翻訳の様に、その意味や成立ちを訴えたいなら必要だが。
要素にはlang属性があって言語を指定できますが 属性値には言語指定とかないですよね? title属性やalt属性に日本語表記と英語表記を併記したいと思ったのですが 要素レベルで併記するしかないですか?
属性値もその要素内に含まれるぞ。 <span lang="en" title="cherry"><img lang="ja" alt="さくらんぼ"></span> ↑こういうことをやりたいのか?
HTMLって元の文書を修飾するものじゃないの?
<a href="" title="ほげ/hoge">ほにゃほにゃ</a> こんな感じでtitle属性に日本語表記と英語表記を併記しているんですが・・・。 「/」が意味不明になるような気がして。 そこで日本語の言語を指定したtitle属性と英語の言語を指定したtitle属性、 みたいにするにはどうするのかな、と・・・。 そもそもこんなことをしようとするのが間違いですか?
936 :
Name_Not_Found :2006/09/12(火) 22:10:52 ID:GIUmx7Tu
目的としてhtmlファイルから必要な要素を抜き出し、xml化するような プログラムを書きたいのですが。 方法として何かありませんか? 現在まさに試行錯誤中です。
HTMLパーサを使う
lintにかけて指摘された箇所を直せばStrictって事でFA?
何がStrictって事でFA、だ。んなもんValid+αでしかない。
確かに。このスレの内容はlintを凌駕している。 Strict中のStrictって感じだな。
いや、Transitionalであっても、lintは必要最低限でしかないから・・・
まあ、しょせん strict なんて飾りですがね。
HTML-lintでの"Valid"は、Strictである爲の『前提條件』だと思う。
うん。でも「必要条件」か?って言霊。
lint100点取れたらとりあえずはOKでしょ。 一般人なら。
チェックオプションを全部外せば簡単に100点取れるぜ
テーブルレイアウトだって100天はとれるものな
たまにlintで100点とってStrictとかいうやついるよなーw
もういいだろlintの話は。 このスレじゃほとんど無関係と言ってもいいくらいのもんだ。
馬鹿にしてるけど殆どのやつは自分もそういう時期あった筈だろw
俺はないな むしろlint使い始めたの最近w
むしろ悪癖をスルーした上でHTML覚えるべき時代
StrictどころかValidでもない腐れHTMLが蔓延っているのは、 腐れテンプレを使い回してるだけの詐欺紛い業者と、 腐れオーサリングツールのせいだろう。
テンプレ業者って詐欺だよな〜藁
そこまで言うなら、Strictでデザインのいいテンプレつくってやれよw
文書も、そのマークアップもStrictなテンプレ・・・。 なかなか良いじゃないか。
漏れはstrictの方が楽だと思うのだが。テーブルレイアウトってソース見にくいしさ。 なぜそんなテンプレを使う奴がいるのか疑問。ましてや他人が作った奴なのに。
>>955 Strictでテンプレ作っても意味ないっしょ
使うやつがなんもわかってないやつ多いし
Transitionalが無難かね
なんのアンカー?
馬鹿には分からない
半年ROMってろ
アプリを公開しているページで、スクリーンショットを掲載するときってどうやってる? 画像の代替文字列が思いつかないんだけど。
そのスクリーンショットによって主にアピールしたいことを書く。 「正規表現でテキストを検索できます」とか「ツールバーはカスタマイズ可能」とか 「シンプルなインターフェイス」とか、そんな感じ。 漫然とスクリーンショットを撮ってるとなにをアピールするか 書けないだろうから、まずスクリーンショットを撮りなおせ。 スクリーンショットがただの飾りだったならalt=""で問題なし。
おお、なるほど。レスサンクスであります。 今ちょっと某Webブラウザのサイトに行ったら、その方式でalt属性がつけられてますた。
>>964 自分ならどうしても画像に置換できないような画像の場合には、
<a href="画像のアドレス"><img src="画像のアドレス" alt="画像のファイル名" /></a>
という風にしている。
文字にできない画像になんでアンカー?
どうしても画像に置換できないような画像を見てみたい。
色を置いただけのような抽象画はオレには少なくとも無理だ。
抽象画とか○○色の画像じゃだめ?
エロ画像は?
>>958 まあ、Strictを宣言しておいて、初心者がいじったときに
body要素直下にインライン要素(普通のテキスト)が置かれるのはアレだし。
俺もTransitionalでいいと思うよ。
>>964-972 無理に、代替文字が必要でない場合は alt="" とすればいいんでない?
kanzaki.comにも書いてあるし。
ただ、画像がハイパーリンクの始点アンカーの場合、Lynxはリンクを辿ることが
出来ないのよね……。
>974 ブラウザ側の欠陥なんて知ったことか。
代替テキストのない画像を画像非表示環境でどうやって表現しろというのか。
自動AA生成
それだ!音声ブラウザなんて気にしない!
ここ、Strictスレだよな?
相手スンナ
Transitional なら body直下にインライン要素とか置いても Valid なんです!><