Ｑ要素：インライン引用文のマークアップについて
1 ：Name_Not_Found：
引用文を示す要素「Q」について、どう取り扱うべきだと思いますか？
もちろん、正しいマークアップという観点から言えば、
”彼は<Q>〜〜〜〜〜</Q>と書いている”
とすべきなんでしょうが、IEの実装が未完成のことから、
”彼は「〜〜〜〜」と書いている”
と、マークアップを避けたほうが、実のところより高い
アクセシビリティを提供できる気もします。
インラインで引用を多用するページを作成しようとしているので
皆さんの意見を参考にさせていただきたいかと存じます。
もちろん、正しいマークアップという観点から言えば、
”彼は<Q>〜〜〜〜〜</Q>と書いている”
とすべきなんでしょうが、IEの実装が未完成のことから、
”彼は「〜〜〜〜」と書いている”
と、マークアップを避けたほうが、実のところより高い
アクセシビリティを提供できる気もします。
インラインで引用を多用するページを作成しようとしているので
皆さんの意見を参考にさせていただきたいかと存じます。
|
|
|
2 ：Name_Not_Found：01/10/11 07:36 ID:ztjwF5Uw
同感。引用符（「」、“”）で事足りる――普通の視覚系UAならば。
q要素は恐らく音声認識ブラウザを考慮してのもの、視覚系には無意味ではないかと感じます。
cite属性も実際の引用にはいちいち不要な場合が多いのですし、
引用元を明示したいのならば、「引用文」（引用元）、と書けばよい。紙の文章ではそれが普通です。
少なくとも幾らcite属性でソースに書かれた所で視認されなければ一般ユーザーにとって無いも同然です。
q要素は恐らく音声認識ブラウザを考慮してのもの、視覚系には無意味ではないかと感じます。
cite属性も実際の引用にはいちいち不要な場合が多いのですし、
引用元を明示したいのならば、「引用文」（引用元）、と書けばよい。紙の文章ではそれが普通です。
少なくとも幾らcite属性でソースに書かれた所で視認されなければ一般ユーザーにとって無いも同然です。
3 ：Name_Not_Found：01/10/11 07:42 ID:xBHicKx2
というか html ってのはあくまで文書の意味付けとして
マークアップするんだから、実装云々とか見えるとか見えないというのとは
関係がないと思うよ。html の話しをするならそういう視点に立たないと不毛でしょう。
あくまでWebっていう巨大なデータベースの中の1リソースとして考えるなら
ちゃんとマークアップした方が良い。と思う。まあどう考えるかは個人の自由だけど。
でも>>1みたいに「インラインで引用を多用する」と自ら言ってるような
ケースなら、自覚もあるんだしちゃんとマークアップしといた方が
あとで喜べる可能性もなくはないんじゃなかろうか。
といいながら"「」"で引用する矛盾に満ちたわたくし。
マークアップするんだから、実装云々とか見えるとか見えないというのとは
関係がないと思うよ。html の話しをするならそういう視点に立たないと不毛でしょう。
あくまでWebっていう巨大なデータベースの中の1リソースとして考えるなら
ちゃんとマークアップした方が良い。と思う。まあどう考えるかは個人の自由だけど。
でも>>1みたいに「インラインで引用を多用する」と自ら言ってるような
ケースなら、自覚もあるんだしちゃんとマークアップしといた方が
あとで喜べる可能性もなくはないんじゃなかろうか。
といいながら"「」"で引用する矛盾に満ちたわたくし。
6 ：Name_Not_Found：01/10/11 08:43 ID:FvdUAZLY
>>6
引用文の場合、既に引用符（「」）がタグの代りに文書の意味付けをマークアップしてるんだから
<q>なんて屋上屋を架すタグは無用では？
そこまでＨＴＭＬタグによるマークアップを徹底する方針ならば、
他の括弧類――（）などはよく使用しますよね？――のためのタグも
新たに必要になる理窟ぢゃありませんか。
引用文の場合、既に引用符（「」）がタグの代りに文書の意味付けをマークアップしてるんだから
<q>なんて屋上屋を架すタグは無用では？
そこまでＨＴＭＬタグによるマークアップを徹底する方針ならば、
他の括弧類――（）などはよく使用しますよね？――のためのタグも
新たに必要になる理窟ぢゃありませんか。
↑は>>5の誤記。自分に返信してどうする。（自問自答？）
8 ：ちょこら：01/10/11 10:57 ID:KzVtNk0A
>>6
>引用文の場合、既に引用符（「」）がタグの代りに文書の意味付けをマークアップしてるんだから
><q>なんて屋上屋を架すタグは無用では？
んー。だからそれはもうhtmlというものとは離れた話になってるよね。
実際"「」"が引用を示すマークアップだという定義はどこにもないわけで。
もしそういう定義がなされてるんなら「」は汎用的といえるけどそうじゃないしね。
だいたい「」って2バイト文字だし。
>そこまでＨＴＭＬタグによるマークアップを徹底する方針ならば
というよりはhtmlってそういうものでしょ?
だからそれが変だと思えばhtmlという規格を使わなければいい話であって。
汎用文書形式としてのhtmlなんだから、
その約束を守らなければ再利用できないリソースになってしまうでしょう。
いや、好きにすればよいと思いますがね。
>引用文の場合、既に引用符（「」）がタグの代りに文書の意味付けをマークアップしてるんだから
><q>なんて屋上屋を架すタグは無用では？
んー。だからそれはもうhtmlというものとは離れた話になってるよね。
実際"「」"が引用を示すマークアップだという定義はどこにもないわけで。
もしそういう定義がなされてるんなら「」は汎用的といえるけどそうじゃないしね。
だいたい「」って2バイト文字だし。
>そこまでＨＴＭＬタグによるマークアップを徹底する方針ならば
というよりはhtmlってそういうものでしょ?
だからそれが変だと思えばhtmlという規格を使わなければいい話であって。
汎用文書形式としてのhtmlなんだから、
その約束を守らなければ再利用できないリソースになってしまうでしょう。
いや、好きにすればよいと思いますがね。
9 ：Name_Not_Found：01/10/11 11:07 ID:8.VLr0Kw
Q:before { content: "\00300C" }
Q:after { content: "\00300D" }
でいいのでは。Netscapeしか対応していないのが難だけど。
Q:after { content: "\00300D" }
でいいのでは。Netscapeしか対応していないのが難だけど。
>>8
>んー。だからそれはもうhtmlというものとは離れた話になってるよね。
ははあ、初めにhtmlありき、なのですか？
私は初めに文書テキストがあって、それにHTMLタグでマークアップしてゆく方針ですが。
文書構造を示す情報はプレーン・テキストには含まれませんから、
それを補完するのがHTMLの役割だと思っとりました。
ですから、既に用意された文書テキストにおいて、
引用符って立派な「引用を示すマークアップ」がされてる場合、
ことさらにhtmlでもマークアップする必要を感じないんですよ。
まあ使用するとしてもこんな感じ↓。
@media visual{
Q {quotes:none;}
}
もちろん、好きにすればいいんですがね。
>んー。だからそれはもうhtmlというものとは離れた話になってるよね。
ははあ、初めにhtmlありき、なのですか？
私は初めに文書テキストがあって、それにHTMLタグでマークアップしてゆく方針ですが。
文書構造を示す情報はプレーン・テキストには含まれませんから、
それを補完するのがHTMLの役割だと思っとりました。
ですから、既に用意された文書テキストにおいて、
引用符って立派な「引用を示すマークアップ」がされてる場合、
ことさらにhtmlでもマークアップする必要を感じないんですよ。
まあ使用するとしてもこんな感じ↓。
@media visual{
Q {quotes:none;}
}
もちろん、好きにすればいいんですがね。
11 ：Name_Not_Found：01/10/11 12:09 ID:6m4ACXq2
Q.A
Q.B
Q.C
という具合にAさんのお言葉、Bさん、Cさんとわけておけば、
Aさんの意見だけを拾い集めるなんてのも正確に容易にできる。
よく「ブラウザの対応」とか言うけど、対応していなくても自分らで活用すればいいじゃん。
どんな形であれ。
鳴かぬなら鳴かせて見せようという発想がほしい。
CSSと組み合わせることではじめて活きるなんてのはよくあるが、エディタ上
で検索しやすいとか、なんらかのスクリプトで処理されるとか、そういう時にだけ
役立つものががあっても別にいいんだ。どう利用しようと漏れの勝手だ。
ということに漏れも最近気づいたのだ。
HTMLは視覚マークアップではないと、知識としては知りつつも、論理マーク
アップであることを積極的に活用しようという発想ができなかったんだ。
「」をどう扱うかどうかにとらわれているってのは、結局は視覚マークアップ的な発想
から抜け出せていないということじゃないのかな。
上記の漏れの意見からいけば<q>「発言」</q>だって、別にいいじゃん。それでも
Q要素としてのタグ打ちをしておけば、何かの役には立つかもしれんということ。
どう役立てるかはあなた次第、読者次第。
ちょこらさんの言うのもそういうことでないかな。
Q.B
Q.C
という具合にAさんのお言葉、Bさん、Cさんとわけておけば、
Aさんの意見だけを拾い集めるなんてのも正確に容易にできる。
よく「ブラウザの対応」とか言うけど、対応していなくても自分らで活用すればいいじゃん。
どんな形であれ。
鳴かぬなら鳴かせて見せようという発想がほしい。
CSSと組み合わせることではじめて活きるなんてのはよくあるが、エディタ上
で検索しやすいとか、なんらかのスクリプトで処理されるとか、そういう時にだけ
役立つものががあっても別にいいんだ。どう利用しようと漏れの勝手だ。
ということに漏れも最近気づいたのだ。
HTMLは視覚マークアップではないと、知識としては知りつつも、論理マーク
アップであることを積極的に活用しようという発想ができなかったんだ。
「」をどう扱うかどうかにとらわれているってのは、結局は視覚マークアップ的な発想
から抜け出せていないということじゃないのかな。
上記の漏れの意見からいけば<q>「発言」</q>だって、別にいいじゃん。それでも
Q要素としてのタグ打ちをしておけば、何かの役には立つかもしれんということ。
どう役立てるかはあなた次第、読者次第。
ちょこらさんの言うのもそういうことでないかな。
12 ：Name_Not_Found：01/10/11 12:29 ID:2a2LVJL6
えと、
><q>「発言」</q>
っていうのはあんまり認められていない。通常のブラウザだと引用符を重ねる
事になるからね。やるなら
><q>発言</q>
になる。もっとも、他の要素だとわざわざ付けられる場合も多い。
>'<samp>エラーです</samp>'
みたいに。このあたりはW3Cの姿勢も一定していない。使う側としては困るんだけど。
><q>「発言」</q>
っていうのはあんまり認められていない。通常のブラウザだと引用符を重ねる
事になるからね。やるなら
><q>発言</q>
になる。もっとも、他の要素だとわざわざ付けられる場合も多い。
>'<samp>エラーです</samp>'
みたいに。このあたりはW3Cの姿勢も一定していない。使う側としては困るんだけど。
13 ：Name_Not_Found：01/10/11 12:35 ID:QgnKZrQ2
>>12
>通常のブラウザだと引用符を重ねる 事になるからね。
通常のブラウザって……ネスケ６だけですよね、引用符表示に対応してるのは？
それへの対策としては>>10みたいに
Q {quotes:none;}
とスタイル設定しとけば、いいんでないの？
>通常のブラウザだと引用符を重ねる 事になるからね。
通常のブラウザって……ネスケ６だけですよね、引用符表示に対応してるのは？
それへの対策としては>>10みたいに
Q {quotes:none;}
とスタイル設定しとけば、いいんでないの？
14 ：Name_Not_Found：01/10/11 14:43 ID:2a2LVJL6
>>13
ttp://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/text.html#h-9.2.2.1
ここを前提にしたつもりだったけど、ひょっとしてWinIEって
今でも引用符付けないの？
ttp://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/text.html#h-9.2.2.1
ここを前提にしたつもりだったけど、ひょっとしてWinIEって
今でも引用符付けないの？
16 ：Name_Not_Found：01/10/11 14:56 ID:1l4FtBig
>>14
N6以外で付けるブラウザなんてないでしょ。
N6以外で付けるブラウザなんてないでしょ。
17 ：Name_Not_Found：01/10/11 15:01 ID:2a2LVJL6
18 ：Name_Not_Found：01/10/11 15:09 ID:1l4FtBig
>>17
N6以外に引用符つけるブラウザなんかあったっけ？
N6以外に引用符つけるブラウザなんかあったっけ？
19 ：ちょこら：01/10/11 15:42 ID:ulXXTCRg
>>10
>ははあ、初めにhtmlありき、なのですか？
いや、はじめにも何も、あなたはhtmlの話をしてるんでしょう?
読み違えてたらすまんが。
>>11
そうそう。そういうこと。
と思って読んでたら最後の行。
そですそです。
そんな感じのことが言いたかっただけ。
>ははあ、初めにhtmlありき、なのですか？
いや、はじめにも何も、あなたはhtmlの話をしてるんでしょう?
読み違えてたらすまんが。
>>11
そうそう。そういうこと。
と思って読んでたら最後の行。
そですそです。
そんな感じのことが言いたかっただけ。
20 ：Name_Not_Found：01/10/11 15:43 ID:5WSQKVTI
>>18
うろ覚えだけど、Lynxとかでも引用符が付いたような。
うろ覚えだけど、Lynxとかでも引用符が付いたような。
21 ：Name_Not_Found：01/10/11 16:24 ID:i69uCOA6
>>18
iCab, MacIE5 では引用符がついた
iCab, MacIE5 では引用符がついた
22 ：Name_Not_Found：01/10/11 16:31 ID:WO9tzEmY
なんで勝手に引用符が着くような仕様にしたんだろうね。
ちょっとでも後方互換性を考慮すれば、まずいことは分かるだろうに。
W3Cってホント馬鹿。
ちょっとでも後方互換性を考慮すれば、まずいことは分かるだろうに。
W3Cってホント馬鹿。
>>19
もちろん問題になってるのはHTMLですが、何より、文書あってのhtmlですよ。
htmlのために文書を書くわけではありませんから。
あなたがHTMLに拘るあまり、事の順序を顛倒しかけてる風に見えたもんで。
こちらの深読みならごめんなさい。
もちろん問題になってるのはHTMLですが、何より、文書あってのhtmlですよ。
htmlのために文書を書くわけではありませんから。
あなたがHTMLに拘るあまり、事の順序を顛倒しかけてる風に見えたもんで。
こちらの深読みならごめんなさい。
24 ：Name_Not_Found：01/10/11 18:34 ID:Qc08zmD.
25 ： ：01/10/11 18:35 ID:rO8tBe5Q
26 ：Name_Founded：01/10/11 19:56 ID:SjH2Lsek
一部のテキストブラウザでは、Q要素などを書面に表現しないので、
マークアップのみで自分の意図を説明したつもりになってもらうと、ちょっと困る。
「そんなアホブラウザ使うお前が悪い」と言われればぐうの音も出ないのですが。
マークアップのみで自分の意図を説明したつもりになってもらうと、ちょっと困る。
「そんなアホブラウザ使うお前が悪い」と言われればぐうの音も出ないのですが。
27 ：Name_Not_Found：01/10/11 20:02 ID:MS1kAM56
<q><qm>「</qm>〜<qm>」</qm></q>
とかどう？
#"Quotation Marks" → "qm"
CSSで引用符をつけるならqm{display:none;}とかすればいいし。
とかどう？
#"Quotation Marks" → "qm"
CSSで引用符をつけるならqm{display:none;}とかすればいいし。
28 ：Name_Not_Found：01/10/11 20:06 ID:G7u/oB.A
29 ：Name_Founded：01/10/11 20:13 ID:SjH2Lsek
>>28
すまん、ちょっと言葉が足りなかった。
Q要素だけの話ではなく、他の様々な要素も無視される。
例えば、blockquoteを何の前触れもなく使われるとかなり面喰らう。
「以下引用」などの緩衝地帯が欲しいな、という希望です。
多少スレ違いなので下げる。
すまん、ちょっと言葉が足りなかった。
Q要素だけの話ではなく、他の様々な要素も無視される。
例えば、blockquoteを何の前触れもなく使われるとかなり面喰らう。
「以下引用」などの緩衝地帯が欲しいな、という希望です。
多少スレ違いなので下げる。
30 ：Name_Not_Found：01/10/11 21:56 ID:yJMAgBaY
「」でええやん、って言ってる人も多いけど、
「」を強調の意で使ってる例もあるわけでしょ？
もちろん、普通に台詞なんかを「」であらわすのも多いわけで。
鍵括弧に明確な引用という意味が無い以上、Q要素の
代替にはならないのでは。
「」を強調の意で使ってる例もあるわけでしょ？
もちろん、普通に台詞なんかを「」であらわすのも多いわけで。
鍵括弧に明確な引用という意味が無い以上、Q要素の
代替にはならないのでは。
31 ：Name_Not_Found：01/10/11 22:02 ID:6m4ACXq2
あと、cite属性で引用元を示すという役割もあるわけで・・・
32 ：Name_Not_Found：01/10/11 22:03 ID:fJ6f.QlU
>>30
視覚系UAで「」を表示すると定義したのがよくなかったんだと思う・・・
視覚系UAで「」を表示すると定義したのがよくなかったんだと思う・・・
33 ：Name_Not_Found：01/10/11 22:14 ID:SVZmUT6.
＞あと、cite属性で引用元を示すという役割もあるわけで・・・
それも目に見える形で表記して貰った方がよっぽどありがたい。（cf.>>2）
よく日記でよその日記や記事を引用で取り上げて云々してるものがあるけど、
その引用された文の筆者が誰で何についての文章なのだか書かずにいきなり
話を展開するものが結構あって、独りよがりで理解に苦しむ。
で、ソース開いてcite属性のURLから辿って、引用元にジャンプして……
手間がかかるし不親切ですよ。
それも目に見える形で表記して貰った方がよっぽどありがたい。（cf.>>2）
よく日記でよその日記や記事を引用で取り上げて云々してるものがあるけど、
その引用された文の筆者が誰で何についての文章なのだか書かずにいきなり
話を展開するものが結構あって、独りよがりで理解に苦しむ。
で、ソース開いてcite属性のURLから辿って、引用元にジャンプして……
手間がかかるし不親切ですよ。
34 ：Name_Not_Found：01/10/11 22:46 ID:cbLr24g6
>>33
「目に見える形で表記」すると、「ありがたい」
「目に見える形で表記」しなければ、「独り善がりで理解に苦しむ」
どうしてそう、極端なのですか。
>手間がかかるし不親切ですよ
なら、手間のかからない親切なブラウザを使えば宜しい。
「目に見える形で表記」すると、「ありがたい」
「目に見える形で表記」しなければ、「独り善がりで理解に苦しむ」
どうしてそう、極端なのですか。
>手間がかかるし不親切ですよ
なら、手間のかからない親切なブラウザを使えば宜しい。
35 ：Name_Not_Found：01/10/12 00:55 ID:MskdWt52
WAI1.0（邦訳:http://www.zspc.com/documents/wcag10/)に
> ある情報を表すための適切なマークアップ言語がある場合には、
> 画像を使わずにそのマークアップ言語を使用する
> (タグ付けによって情報の意味を伝えるため)。[優先度2]
ってのがあるけど、このような場合の記号も含まれるのかなぁ。
それは兎も角。引用を表す為に別に「」を拘らずに、
背景色変えるとか、下線、上線付けるとかでも良い気がします。
> ある情報を表すための適切なマークアップ言語がある場合には、
> 画像を使わずにそのマークアップ言語を使用する
> (タグ付けによって情報の意味を伝えるため)。[優先度2]
ってのがあるけど、このような場合の記号も含まれるのかなぁ。
それは兎も角。引用を表す為に別に「」を拘らずに、
背景色変えるとか、下線、上線付けるとかでも良い気がします。
36 ：Name_Not_Found：01/10/12 03:50 ID:gBab0sx2
>>34
やれやれ、どっちが極端なんだか、なあ。
Q要素のcite属性を表示する「手間のかからない親切なブラウザ」なんてあれば苦労は無い。
最終的にはＵＡではなく人間に読ませるための文書だってこと、忘れてないかね。
やれやれ、どっちが極端なんだか、なあ。
Q要素のcite属性を表示する「手間のかからない親切なブラウザ」なんてあれば苦労は無い。
最終的にはＵＡではなく人間に読ませるための文書だってこと、忘れてないかね。
37 ：Name_Not_Found：01/10/12 03:59 ID:UMZEY.2k
>>34
Q要素にも対応してるのかどうかは知らんが、BLOCKQUOTE要素のcite属性なら「手間のかからない親切なブラウザ」はある。
Q要素にも対応してるのかどうかは知らんが、BLOCKQUOTE要素のcite属性なら「手間のかからない親切なブラウザ」はある。
38 ：Name_Not_Found：01/10/12 04:12 ID:tFVTYaWw
>>37
具体的には？ あんまり一般的でないブラウザの話されても困るんですけど。
それとcite属性に記す位ならば、視認できる<cite>要素で明示すればいいのに、と感じます（blockquoteの場合）。
具体的には？ あんまり一般的でないブラウザの話されても困るんですけど。
それとcite属性に記す位ならば、視認できる<cite>要素で明示すればいいのに、と感じます（blockquoteの場合）。
39 ：Name_Not_Found：01/10/12 05:44 ID:UMZEY.2k
40 ：Name_Not_Found：01/10/12 05:46 ID:Pb5IWPJ2
とりあえず逆から考えてみれや。
引用符や括弧を使ったとして、それをブラウザがどうやって解釈する？
好きなように表記すればいいが、ブラウザからのサービスをあてにするなら
Q要素を使うしかないということ。視覚とか音声とか全然関係なし。
ましてや現況における対応状況がどうだという事は全く別問題。
少なくともいくら引用符や括弧で文を囲ったところで
「ブラウザは」それを引用とは認識しないよ。
それで構わなけりゃQ使う必要はない。
しかしもちろん「検索の条件に含める」とか
「その要素だけを抽出して表示」などという芸当はできない。
たとえそういうブラウジングプログラムを誰かが組んだとしてもね。
引用符や括弧を使ったとして、それをブラウザがどうやって解釈する？
好きなように表記すればいいが、ブラウザからのサービスをあてにするなら
Q要素を使うしかないということ。視覚とか音声とか全然関係なし。
ましてや現況における対応状況がどうだという事は全く別問題。
少なくともいくら引用符や括弧で文を囲ったところで
「ブラウザは」それを引用とは認識しないよ。
それで構わなけりゃQ使う必要はない。
しかしもちろん「検索の条件に含める」とか
「その要素だけを抽出して表示」などという芸当はできない。
たとえそういうブラウジングプログラムを誰かが組んだとしてもね。
41 ：Name_Not_Found：01/10/12 05:57 ID:zdCNEfik
>>39
えっ、うそ！ NN6が？ ――と思って試してみたけれど
blockquoteタグのcite属性にURIを記してもうちのNetscape 6.1では
やはり何も起こらず。ウソツキ。
＞あと、CITE要素はアンカーではない。
それが何か？ <cite><a>〜</a></cite>で済む話では。
えっ、うそ！ NN6が？ ――と思って試してみたけれど
blockquoteタグのcite属性にURIを記してもうちのNetscape 6.1では
やはり何も起こらず。ウソツキ。
＞あと、CITE要素はアンカーではない。
それが何か？ <cite><a>〜</a></cite>で済む話では。
42 ：Name_Not_Found：01/10/12 06:01 ID:JwXUusi.
>>41
citeの指定された要素の上で右クリック→プロパティ
citeの指定された要素の上で右クリック→プロパティ
43 ：ちょこら：01/10/12 06:07 ID:LMi0ik9Y
>>36
>最終的にはＵＡではなく人間に読ませるための文書だってこと、忘れてないかね。
まず初めに人間ではなくマシンで処理できるように約束事を決めた汎用的な文書データ形式だってこと、忘れてないかね。
っていうか君レベル低い。
あと態度悪い。
まともに話してる人いっぱいいるんだからちゃんと耳を傾けろよ。
議論にも何もなりゃしない。
>最終的にはＵＡではなく人間に読ませるための文書だってこと、忘れてないかね。
まず初めに人間ではなくマシンで処理できるように約束事を決めた汎用的な文書データ形式だってこと、忘れてないかね。
っていうか君レベル低い。
あと態度悪い。
まともに話してる人いっぱいいるんだからちゃんと耳を傾けろよ。
議論にも何もなりゃしない。
44 ：41：01/10/12 06:10 ID:zdCNEfik
>>42
おおそんな機能が。有り難う、知りませんでした。
でも少し手間だし、やっぱり<cite>要素で見える形にしてくれた方が便利で、
アクセシビリティーに適ってるのではないかと感じます。
>>40
>「ブラウザは」それを引用とは認識しないよ。
>それで構わなけりゃQ使う必要はない。
読む人間が認識してくれれば十分ですので、いまのところ必要ありません。
q要素だけ抽出したい状況ってのがどうも想像つきません。
おおそんな機能が。有り難う、知りませんでした。
でも少し手間だし、やっぱり<cite>要素で見える形にしてくれた方が便利で、
アクセシビリティーに適ってるのではないかと感じます。
>>40
>「ブラウザは」それを引用とは認識しないよ。
>それで構わなけりゃQ使う必要はない。
読む人間が認識してくれれば十分ですので、いまのところ必要ありません。
q要素だけ抽出したい状況ってのがどうも想像つきません。
45 ：40：01/10/12 06:18 ID:Pb5IWPJ2
>44
むろんそれなら問題ないよ。そう言ってるじゃん。
むろんそれなら問題ないよ。そう言ってるじゃん。
46 ：Name_Not_Found：01/10/12 06:27 ID:UMZEY.2k
＞読む人間が認識してくれれば十分ですので、いまのところ必要ありません。
＞q要素だけ抽出したい状況ってのがどうも想像つきません。
ならてめぇが使わなきゃ言いだけの話だろ┐(´ー｀)┌
＞q要素だけ抽出したい状況ってのがどうも想像つきません。
ならてめぇが使わなきゃ言いだけの話だろ┐(´ー｀)┌
48 ：41：01/10/12 06:34 ID:zdCNEfik
>>46
同じではありませんよ。
<q cite="URI" title="出典名">引用文</q>
<q>「引用文」</q><cite><a href="URL">（『出典名』）</a></cite>
どちらが目で見てわかりやすく、ユーザーに親切な書き方ですか？
同じではありませんよ。
<q cite="URI" title="出典名">引用文</q>
<q>「引用文」</q><cite><a href="URL">（『出典名』）</a></cite>
どちらが目で見てわかりやすく、ユーザーに親切な書き方ですか？
49 ：Name_Not_Found：01/10/12 07:05 ID:wiP3rIJo
目で見てわかりやすいといえばそうだろうけど
常時 cite 要素で書くのは目で見てくどい。
「こっちが優れている」的なものではないと思うがどうか。
常時 cite 要素で書くのは目で見てくどい。
「こっちが優れている」的なものではないと思うがどうか。
50 ：Name_Not_Found：01/10/12 07:12 ID:Jff62qRc
>48
なぜCITE要素にHREF属性がなくてCITE属性がURIなのか
ぜんぜん想像もつかないだろ？(w
なぜCITE要素にHREF属性がなくてCITE属性がURIなのか
ぜんぜん想像もつかないだろ？(w
確かにくどくなりがちですから、cite要素は適宜略しても可ですね。
ただ、>>33の例みたいに文脈がわからず話が見えない書き方は困りもの。
何かの役に立つかもしれないから一応<q>で括っておけってのはいいとしても、
要は、q要素やcite属性に頼り切らず、マークアップする以前の文書の段階で
読者に配慮して書くのが肝腎ってことになりますか。
いくらマークアップが正しくとも大元の文書に不備があっては、ね？
ただ、>>33の例みたいに文脈がわからず話が見えない書き方は困りもの。
何かの役に立つかもしれないから一応<q>で括っておけってのはいいとしても、
要は、q要素やcite属性に頼り切らず、マークアップする以前の文書の段階で
読者に配慮して書くのが肝腎ってことになりますか。
いくらマークアップが正しくとも大元の文書に不備があっては、ね？
52 ：yuu ◆xo3ilszg ：01/10/12 09:50 ID:AooS.19s
>>48
<q>「引用文」</q><cite><a href="URL">（『出典名』）</a></cite>
この場合、このq要素と続くcite要素が”対”の関係になっているという
保証がないのでは。
冗長ともいえるが、
<p><q cite="URI" title="出典名">引用文</q>><cite><a href="URL">（『出典名』）</a></cite></p>
こういうのが、親切な記述というのかもしれない。
<q>「引用文」</q><cite><a href="URL">（『出典名』）</a></cite>
この場合、このq要素と続くcite要素が”対”の関係になっているという
保証がないのでは。
冗長ともいえるが、
<p><q cite="URI" title="出典名">引用文</q>><cite><a href="URL">（『出典名』）</a></cite></p>
こういうのが、親切な記述というのかもしれない。
それだってqとciteを関連付けることはできないでしょ。
しかも何でp? 論理的に段落を構成するものでもないでしょ?
(もし構成するならblockquote使うべし)
だいたいqもciteもinline要素なんだから、何らかのblocklevel要素で挟まれていることは当然であるわけで、
しかも親要素はpである可能性が高い。pはpを中身に取れないので、div+適当なclassがよい。
しかも何でp? 論理的に段落を構成するものでもないでしょ?
(もし構成するならblockquote使うべし)
だいたいqもciteもinline要素なんだから、何らかのblocklevel要素で挟まれていることは当然であるわけで、
しかも親要素はpである可能性が高い。pはpを中身に取れないので、div+適当なclassがよい。
54 ：Name_Not_Found：01/10/12 10:32 ID:mIF/u7lY
早くちょこら君に手間が掛からない親切なブラウザを教えてもらいたいなあ。
一般の家庭用PC環境で使用できるものにしてね♪
低レベルで議論避けてるのって43だよね。(ﾜﾗ
一般の家庭用PC環境で使用できるものにしてね♪
低レベルで議論避けてるのって43だよね。(ﾜﾗ
55 ：53：01/10/12 10:33 ID:mIF/u7lY
>何らかのblocklevel要素で挟まれていることは当然であるわけで、
修正
何らかのblock-level要素の内容であることは当然であるわけで、
修正
何らかのblock-level要素の内容であることは当然であるわけで、
56 ：Name_Not_Found：01/10/12 10:51 ID:Rprrysg2
yuuさんに難癖つける人って初めて見たような気がするなあ。
57 ：Name_Not_Found：01/10/12 10:56 ID:UMZEY.2k
58 ：yuu ◆xo3ilszg ：01/10/12 11:06 ID:AooS.19s
blockquoteだとしても、その中に入るのはやはり
<p><q cite="URI" title="出典名">引用文</q><cite><a href="URL">（『出典名』）</a></cite></p>
では?
<p><q cite="URI" title="出典名">引用文</q><cite><a href="URL">（『出典名』）</a></cite></p>
では?
59 ：yuu ◆xo3ilszg ：01/10/12 11:08 ID:AooS.19s
それと蛇足かもしれないが、
パラグラフは必ずしも段落であるとは思わないのだが…
というか、パラグラフはパラグラフだと思う。
パラグラフは必ずしも段落であるとは思わないのだが…
というか、パラグラフはパラグラフだと思う。
60 ：>58：01/10/12 11:17 ID:wSUSTDyg
いや違うって。もし引用文それ自体が段落を構成するならば、
もはやインラインではなくブロックレベルとして扱うべきなんだって。
そしたら、qの代わりにblockquoteを使うべきでしょう。
もはやインラインではなくブロックレベルとして扱うべきなんだって。
そしたら、qの代わりにblockquoteを使うべきでしょう。
61 ：U-Z ◆UZ.Eg.Bg ：01/10/12 11:47 ID:jqCDHOC.
>>58
それだと引用の引用となりそうですが。
>>60
インラインに引用部分を書くのであれば、q要素。
引用部分だけで独立したブロックを成立させるのであれば
blockquote要素として、引用する側ががマークアップするって
ことじゃないでしょうか。
例えば、
A氏は「○○(元文章で一段落であった文とでも想像して下さい)」と言っているが……
と
A氏は以下のように述べている。
「○○」
しかしながら……
のように、同じ文を引用するとしても、マークアップ前の文章の構成で
q要素ともなりうるしblockquote要素ともなりうると思いますが。
それだと引用の引用となりそうですが。
>>60
インラインに引用部分を書くのであれば、q要素。
引用部分だけで独立したブロックを成立させるのであれば
blockquote要素として、引用する側ががマークアップするって
ことじゃないでしょうか。
例えば、
A氏は「○○(元文章で一段落であった文とでも想像して下さい)」と言っているが……
と
A氏は以下のように述べている。
「○○」
しかしながら……
のように、同じ文を引用するとしても、マークアップ前の文章の構成で
q要素ともなりうるしblockquote要素ともなりうると思いますが。
62 ：Name_Not_Found：01/10/12 13:09 ID:gFFXR6Is
普通の人はWebで文書を公開するための手段としてHTMLを考えている。
最終的な目的はHTMLでマークアップすることではなく、Webで文書を公開すること。
だから、正しくマークアップすることよりも、どのブラウザで見ても誤解を与えない
表現の方が優先するのではないでしょうか？
最終的な目的はHTMLでマークアップすることではなく、Webで文書を公開すること。
だから、正しくマークアップすることよりも、どのブラウザで見ても誤解を与えない
表現の方が優先するのではないでしょうか？
63 ：Name_Not_Found：01/10/12 14:42 ID:gsDhM9pk
>62
Webで文書を公開する→どのブラウザで見ても…
っておかしいやん。
Webで文書を公開するというのは、いわゆるブラウザに限らず
さまざまなUAによって文書が解釈されるということでしょ？
「」のような曖昧なもので引用を表現されるほうが、よっぽど
誤解される可能性があると思いますが。
Webで文書を公開する→どのブラウザで見ても…
っておかしいやん。
Webで文書を公開するというのは、いわゆるブラウザに限らず
さまざまなUAによって文書が解釈されるということでしょ？
「」のような曖昧なもので引用を表現されるほうが、よっぽど
誤解される可能性があると思いますが。
64 ：yuu ◆xo3ilszg ：01/10/12 14:48 ID:AooS.19s
65 ：yuu ◆xo3ilszg ：01/10/12 14:52 ID:AooS.19s
>>60
で、blockquoteかqかどちらが適切化は、そのブロックレベルで構成
すべきとされる引用文に、完全に依存するわけであり、何ともいえない。
qで書かれると前提されているということは、それが適切だったのであろう。
とか思うんだけど。
で、blockquoteかqかどちらが適切化は、そのブロックレベルで構成
すべきとされる引用文に、完全に依存するわけであり、何ともいえない。
qで書かれると前提されているということは、それが適切だったのであろう。
とか思うんだけど。
66 ：Name_Not_Found：01/10/12 14:58 ID:gFFXR6Is
>>63
引用とわかるような書き方をすれば、「」で引用を表現することは可能です。
印刷物ではそのような表現がなされています。
少なくとも現時点において、ブラウザによって表示されるかわからない引用符や、
cite属性に頼るのは危険じゃないでしょうか？
引用とわかるような書き方をすれば、「」で引用を表現することは可能です。
印刷物ではそのような表現がなされています。
少なくとも現時点において、ブラウザによって表示されるかわからない引用符や、
cite属性に頼るのは危険じゃないでしょうか？
67 ：Name_Not_Found：01/10/12 14:59 ID:.u8jrCa6
>>63
でも単に<q>だけで引用句を括った場合、特にスタイル指定をしない限り、
ＩＥなど多くのＵＡでは他のインライン・テキストと区別無い状態になる。
つまり引用句であるか否かも判別できないわけです。よほど誤解されやすい。
また仮に文字色や下線などのスタイルをq要素に指定してあっても、
伝統的に引用符として使用されてきた「」や“”と違って
そのスタイルが引用を意味することは必ずしも判然としない憾みがあります。
そもそもＨＴＭＬ文書はＣＳＳオフでも十分読むのに支障無いものでなければならない筈ですし。
したがって、視覚系以外のＵＡのため<q＞タグでマークアップするのはいいが、
その場合、@media visual{ Q {quotes:none;}} とスタイル設定をして、
その上で<q>「引用句」</q>なり<q>“引用句”</q>と引用符を入れて書くことが望ましいかと。
でも単に<q>だけで引用句を括った場合、特にスタイル指定をしない限り、
ＩＥなど多くのＵＡでは他のインライン・テキストと区別無い状態になる。
つまり引用句であるか否かも判別できないわけです。よほど誤解されやすい。
また仮に文字色や下線などのスタイルをq要素に指定してあっても、
伝統的に引用符として使用されてきた「」や“”と違って
そのスタイルが引用を意味することは必ずしも判然としない憾みがあります。
そもそもＨＴＭＬ文書はＣＳＳオフでも十分読むのに支障無いものでなければならない筈ですし。
したがって、視覚系以外のＵＡのため<q＞タグでマークアップするのはいいが、
その場合、@media visual{ Q {quotes:none;}} とスタイル設定をして、
その上で<q>「引用句」</q>なり<q>“引用句”</q>と引用符を入れて書くことが望ましいかと。
あ、ちょっと建設的になってる。けど。。
>>54
何で僕があなたに「手がかからない親切なブラウザ」
を教えてあげなければいけないんですか?
っていうかなんですか?それ。
誰かと間違えてる?
>低レベルで議論避けてるのって43だよね。(ﾜﾗ
これには同意。
>>56
こないだもっとすごいのがいたよ。
あと、誰が誰だかサッパリわからないんだけど、
>>66みたいな意見の人はこれをどうぞ。
http://kanzaki.com/docs/html/lesson1.html#S10
なぜsage進行?
>>54
何で僕があなたに「手がかからない親切なブラウザ」
を教えてあげなければいけないんですか?
っていうかなんですか?それ。
誰かと間違えてる?
>低レベルで議論避けてるのって43だよね。(ﾜﾗ
これには同意。
>>56
こないだもっとすごいのがいたよ。
あと、誰が誰だかサッパリわからないんだけど、
>>66みたいな意見の人はこれをどうぞ。
http://kanzaki.com/docs/html/lesson1.html#S10
なぜsage進行?
おお。俺のIDｶｺｲｲ!
>>66
感情的発言は抑制した方がいいですよ。冷静にね。
http://kanzaki.com/docs/html/lesson1.html#S10は読んだことありますが。
「最初の利用者」はＵＡでも、最終的には人間の利用者に読ませるのが目的のはず。
目的と手段の本末顛倒にご注意あれ。
感情的発言は抑制した方がいいですよ。冷静にね。
http://kanzaki.com/docs/html/lesson1.html#S10は読んだことありますが。
「最初の利用者」はＵＡでも、最終的には人間の利用者に読ませるのが目的のはず。
目的と手段の本末顛倒にご注意あれ。
70は>>68の誤記。失礼しました。
>>58は下記の方がよくありませんか？
<blockquote cite="URI" title="出典名"><p>引用文</p><p><cite><a href="URL">（『出典名』）</a></cite></p></blockquote>
qの場合は、
<p>〜〜<q cite="URI" title="出典名">「引用句」</q><cite><a href="URL">（『出典名』）</a></cite>〜〜</p>
連続して書かれてあれば、q要素とcite要素が対であることは自明で、特に工夫は要らないかと。
<blockquote cite="URI" title="出典名"><p>引用文</p><p><cite><a href="URL">（『出典名』）</a></cite></p></blockquote>
qの場合は、
<p>〜〜<q cite="URI" title="出典名">「引用句」</q><cite><a href="URL">（『出典名』）</a></cite>〜〜</p>
連続して書かれてあれば、q要素とcite要素が対であることは自明で、特に工夫は要らないかと。
>>70
>感情的発言は抑制した方がいいですよ。冷静にね。
あ、いや、すいません。>>43を書いたときは冷静でなかったんですが、
今は冷静です。感情的に見えたらすいません。
>「最初の利用者」はＵＡでも、最終的には人間の利用者に読ませるのが目的のはず。
そのとおりですが、僕は最終的に人間の利用者に読ませるのはブラウザの仕事だと思います。
現状でメジャーなブラウザがそのような仕事をしてくれないのは問題というか困りますが、
だからと言ってq要素を「」で代用するというような論調には賛同できません。
僕自身は普段手抜きですのでqでマークアップしないこともしばしばです。
実際にマークアップするかどうかは個人の裁量で決めればよいと思います。
>>27みたいなのが面白いかな、と思いました。
>感情的発言は抑制した方がいいですよ。冷静にね。
あ、いや、すいません。>>43を書いたときは冷静でなかったんですが、
今は冷静です。感情的に見えたらすいません。
>「最初の利用者」はＵＡでも、最終的には人間の利用者に読ませるのが目的のはず。
そのとおりですが、僕は最終的に人間の利用者に読ませるのはブラウザの仕事だと思います。
現状でメジャーなブラウザがそのような仕事をしてくれないのは問題というか困りますが、
だからと言ってq要素を「」で代用するというような論調には賛同できません。
僕自身は普段手抜きですのでqでマークアップしないこともしばしばです。
実際にマークアップするかどうかは個人の裁量で決めればよいと思います。
>>27みたいなのが面白いかな、と思いました。
74 ：Name_Not_Found：01/10/12 18:21 ID:c/WTb2Dk
話はそれるが、引用符は"quote"より“quote”がいいね（英語の場合）。
'quote'より‘quote’。左右向きが異なるのが見えますか。
q:beforeやq:afterで指定すればいい。
'quote'より‘quote’。左右向きが異なるのが見えますか。
q:beforeやq:afterで指定すればいい。
75 ：Name_Not_Found：01/10/12 20:26 ID:TnnR/Ea2
<q><span class="tmp">「</span>吾輩は猫である。名前はまだ無い。<span class="tmp">」</span></q>
q span.tmp{display:none;}
て方法が<cite>ユニバーサルHTML/XHTML</cite>にあるけど？
がいしゅつだったらスマソ。
q span.tmp{display:none;}
て方法が<cite>ユニバーサルHTML/XHTML</cite>にあるけど？
がいしゅつだったらスマソ。
76 ：Name_Not_Found：01/10/12 20:27 ID:Vpo3mROk
iCabは引用系要素のcite属性に対応していなかったっけ？
77 ：Name_Not_Found：01/10/12 20:29 ID:TnnR/Ea2
>>76
してるよ。
してるよ。
78 ：Name_Not_Found：01/10/12 20:37 ID:wWVElmwY
>>75
CSSは読まないけどqに引用符を付けるブラウザには
どう対応するんだろ、それ？
問題点は、仕様にはあるけどメジャーブラウザであるWinIEが
全然対応してないって部分に集約されると思うんだけど、
究極的にはサーバ側でブラウザを判別して
HTMLを書き換えるしかないのかなぁ。
CSSは読まないけどqに引用符を付けるブラウザには
どう対応するんだろ、それ？
問題点は、仕様にはあるけどメジャーブラウザであるWinIEが
全然対応してないって部分に集約されると思うんだけど、
究極的にはサーバ側でブラウザを判別して
HTMLを書き換えるしかないのかなぁ。
79 ：75：01/10/12 20:42 ID:TnnR/Ea2
WinIE対策なら、qは色を変えるという方法がメジャーと思われ。
NN4.xでは使えないけど。
その辺りに引用符をつけたいときは>>75。
ただしOmniwebとかのマイナーブラウザでどうなるかは知らない。
NN4.xでは使えないけど。
その辺りに引用符をつけたいときは>>75。
ただしOmniwebとかのマイナーブラウザでどうなるかは知らない。
80 ：yuu ◆xo3ilszg ：01/10/12 20:41 ID:AooS.19s
81 ：Name_Not_Found：01/10/12 20:44 ID:TnnR/Ea2
もじらでもスタイルシートOFFでは勿論駄目だしな。
82 ：Name_Not_Found：01/10/12 20:47 ID:TnnR/Ea2
<blockquote cite="URI" title="出典名"><p>引用文</p><p><cite><a href="URI">（『出典名』）</a></cite></p></blockquote> ではなく、
<blockquote cite="URI" title="出典名"><p>引用文</p><div><cite><a href="URI">（『出典名』）</a></cite></div></blockquote>じゃないかなと思うのだが。
出典名が段落か？
<blockquote cite="URI" title="出典名"><p>引用文</p><div><cite><a href="URI">（『出典名』）</a></cite></div></blockquote>じゃないかなと思うのだが。
出典名が段落か？
83 ：Name_Not_Found：01/10/12 22:32 ID:hN52w2cI
blockquoteの中にciteを入れると、「引用が引用している出典（引用の引用）」を
表していると（来訪者に）受け取られかねないと思うんですが、いいんでしょうか。
表していると（来訪者に）受け取られかねないと思うんですが、いいんでしょうか。
84 ：Name_Not_Found：01/10/12 23:07 ID:bV3eXsmg
というか、引用元明示なら blockquote:before や blockquote:after に出したら?
どうしても書きたいなら、以下のようにマークアップしてみたらどうよ。
<div class="quotes">
<blockquote cite="..." title="...">
<p>引用文</p>
</blockquote>
<div class="cite">
<p>出典 : <a href="...">...</a></p>
</div>
</div>
どうしても書きたいなら、以下のようにマークアップしてみたらどうよ。
<div class="quotes">
<blockquote cite="..." title="...">
<p>引用文</p>
</blockquote>
<div class="cite">
<p>出典 : <a href="...">...</a></p>
</div>
</div>
85 ：Name_Not_Found：01/10/12 23:24 ID:wWVElmwY
86 ：84：01/10/12 23:39 ID:bV3eXsmg
>>85
正直、何故そこに議論が起きるのかがわからない。
引用された部分を明示するのに鈎括弧でくくりたいなら
「<q>引用文</q>」とかにしたらいいんじゃないの?
自然言語として記述された文章で引用文を「」で括っていたとしたら、
引用された部分である内側の文章だけをマークアップしたらいいだけ。
元となる文章があって、それをコンピュータがわかるように
マークアップしていくのだから。
どのように表示されるかとか、そういうことを考えて
マークアップはするものじゃないでしょう。
正直、何故そこに議論が起きるのかがわからない。
引用された部分を明示するのに鈎括弧でくくりたいなら
「<q>引用文</q>」とかにしたらいいんじゃないの?
自然言語として記述された文章で引用文を「」で括っていたとしたら、
引用された部分である内側の文章だけをマークアップしたらいいだけ。
元となる文章があって、それをコンピュータがわかるように
マークアップしていくのだから。
どのように表示されるかとか、そういうことを考えて
マークアップはするものじゃないでしょう。
87 ：Name_Not_Found：01/10/13 01:22 ID:i5FPriyA
>86
そういう正論はずっと前に出ているのだが
このスレに来てる多くの人々には理解できないらしい。
なんだかCITE属性に
”広辞苑第４版”だの
”夏目漱石著、新潮社刊「吾輩は猫である」４８ページ”
とか書くアホウがいそうだな。
CITE要素の中身に”http://〜”とか書くのは有りだけどな。
どうせこう言ってもぜんぜん解らんだろうな。
なぜDIVやCITE要素にCITE属性が要る！？
特定ブラウザでCITE要素のアクセシビリティが悪いつーなら
既出だがCITEとAを併用するのも有り。
冗長だが出典を本文に書くのだから目に触れるのは確実だ。
ただし、本来URIで表記できる出典なら
CITE属性に書くのがスジだけどね。
「括弧や引用符がダブるくらいなら首吊った方がマシ！」ってんなら
Qによるマークアップは不可能だな。
CSSに対応していないブラウザがどうレンダリングするかなんて
わかったもんじゃないからな（対応してても解釈の異なる事だってありうる）。
IEとN6だけとかブラウザを絞るならCSSで対処すりゃいいんじゃないの？
いずれにせよ議論する価値のある問題ではないのでsage
そういう正論はずっと前に出ているのだが
このスレに来てる多くの人々には理解できないらしい。
なんだかCITE属性に
”広辞苑第４版”だの
”夏目漱石著、新潮社刊「吾輩は猫である」４８ページ”
とか書くアホウがいそうだな。
CITE要素の中身に”http://〜”とか書くのは有りだけどな。
どうせこう言ってもぜんぜん解らんだろうな。
なぜDIVやCITE要素にCITE属性が要る！？
特定ブラウザでCITE要素のアクセシビリティが悪いつーなら
既出だがCITEとAを併用するのも有り。
冗長だが出典を本文に書くのだから目に触れるのは確実だ。
ただし、本来URIで表記できる出典なら
CITE属性に書くのがスジだけどね。
「括弧や引用符がダブるくらいなら首吊った方がマシ！」ってんなら
Qによるマークアップは不可能だな。
CSSに対応していないブラウザがどうレンダリングするかなんて
わかったもんじゃないからな（対応してても解釈の異なる事だってありうる）。
IEとN6だけとかブラウザを絞るならCSSで対処すりゃいいんじゃないの？
いずれにせよ議論する価値のある問題ではないのでsage
88 ：Name_Not_Found：01/10/13 01:23 ID:3SoxEz9w
89 ：yuu ◆xo3ilszg ：01/10/13 01:25 ID:fbkgAl2A
個人的には、divの直下にインライン要素しか来ないようなマークアップが嫌いだ。
>>87
むしろそういう場合は urn:isbn:4-xxx.... だろう。
cite 属性は URL ではなく URI だから。
まぁ、そうではなく cite は引用に限らず参照した場合にも
利用することができるから (ins 要素とか) div などにも
利用できないことはない。
cite 要素の cite 属性が付くとしたら、引用元/参照ソースを
明示するだけだから構わないとも思う。
たとえば COM-CHAT の発言欄自動削除の部分をゆいチャットから
パクって来ているが、そういう部分は cite 要素で明示して
cite 属性でゆいチャットのスクリプトの所在を指すとかね。
そのまんまパクっているのであれば cite 要素よりは q 要素や
blockquote 要素の方が適していることになる。
cite はあくまで cite であって quote じゃないってことを
理解していなければ、適切にマークアップなんてできないんじゃないかな。
# 早く tripper で良い trip code 出てこないかな……。
つか、「q 要素だと引用符が出るから嫌だ」とか、そういうのって
そもそも HTML を理解していない証拠だよなぁ。
むしろそういう場合は urn:isbn:4-xxx.... だろう。
cite 属性は URL ではなく URI だから。
まぁ、そうではなく cite は引用に限らず参照した場合にも
利用することができるから (ins 要素とか) div などにも
利用できないことはない。
cite 要素の cite 属性が付くとしたら、引用元/参照ソースを
明示するだけだから構わないとも思う。
たとえば COM-CHAT の発言欄自動削除の部分をゆいチャットから
パクって来ているが、そういう部分は cite 要素で明示して
cite 属性でゆいチャットのスクリプトの所在を指すとかね。
そのまんまパクっているのであれば cite 要素よりは q 要素や
blockquote 要素の方が適していることになる。
cite はあくまで cite であって quote じゃないってことを
理解していなければ、適切にマークアップなんてできないんじゃないかな。
# 早く tripper で良い trip code 出てこないかな……。
つか、「q 要素だと引用符が出るから嫌だ」とか、そういうのって
そもそも HTML を理解していない証拠だよなぁ。
91 ：Name_Not_Found：01/10/13 07:33 ID:f0sn5WL6
なんかq要素非対応ブラウザ(要はIEね)の為に、引用部に色をつければいいんじゃないかと言っている人いますけど
、、
<q>を解釈できないということは、qに指定したstyleも無視してしまうので、
彼は<q>逝ってよし</q>と言った
q {color:#0088ff;}
としても色は変わらない。結局
彼は<q><span class="quote">逝ってよし</span></q>と言った
.quote {color:#0088ff;}
と冗長的なmark-upになってしまわざるを得ない。
<q>を解釈できるuser-agentから見れば「逝ってよし」の部分が二重に意味付けされているのも変。
それに、読み手側が色を認識できるとは限らないし、、、、
色を変えるよりも、引用符で囲むのが正書法なのだから、これは不適切な回避方法じゃないかと思いますが。
、、
<q>を解釈できないということは、qに指定したstyleも無視してしまうので、
彼は<q>逝ってよし</q>と言った
q {color:#0088ff;}
としても色は変わらない。結局
彼は<q><span class="quote">逝ってよし</span></q>と言った
.quote {color:#0088ff;}
と冗長的なmark-upになってしまわざるを得ない。
<q>を解釈できるuser-agentから見れば「逝ってよし」の部分が二重に意味付けされているのも変。
それに、読み手側が色を認識できるとは限らないし、、、、
色を変えるよりも、引用符で囲むのが正書法なのだから、これは不適切な回避方法じゃないかと思いますが。
92 ：Name_Not_Found：01/10/13 08:06 ID:f0sn5WL6
>90
>つか、「q 要素だと引用符が出るから嫌だ」とか、そういうのって
>そもそも HTML を理解していない証拠だよなぁ。
その解釈には異議あり。つか、ひねくれた見方と思われ。
そもそもq要素自体の定義付けがルール違反なの。
新たなDTDと仕様を勧告するにあたって、W3Cは後方互換性を意識しなければならないにもかかわらず、
q要素については、それが無視されている。
「browserは解釈できないmark-upを無視する」という大前提があるのに、
「UAはq要素の前後を引用符でrenderしなければならず、書き手は引用符を書くべきではない」
というムチャクチャな勧告を出しているから、ややこしくなる。
「UAはq要素の前後に引用符を勝手に付け足してはならない」という勧告であれば、何の問題もなかったのに。。
HTMLは最終的に人間が読むという事実を忘れるべきではない。
だから、人間が不自然と感じるようrenderされる蓋然性のあるmark-upは避けるべき。
ただ、コード書きとしては、引用部にmark-upなされていると、活用できるのでうれしい。
が、「引用」という一つの論理要素について、二重にmark-upするのは回避すべき。
だから下記の要件を同時に満たす解決法でなければならない。
・UAが<q>を解釈できるか否かにかかわらず、一重の引用符で囲まれるべき。
・一つの論理要素に、二重にmark-up(すなわち論理意味付け)をしてはならない。
私は
彼は「<q>逝ってよし</q>」と言った
q {quotes:none;}
を推奨したい。
もっとも「q要素を勧告通り解釈できるが、quotesプロパティを解釈できない」ブラウザでは
彼は「「逝ってよし」」と言った
となってしまうが、、、そんな中途半端なブラウザがないことを祈る。(w
>つか、「q 要素だと引用符が出るから嫌だ」とか、そういうのって
>そもそも HTML を理解していない証拠だよなぁ。
その解釈には異議あり。つか、ひねくれた見方と思われ。
そもそもq要素自体の定義付けがルール違反なの。
新たなDTDと仕様を勧告するにあたって、W3Cは後方互換性を意識しなければならないにもかかわらず、
q要素については、それが無視されている。
「browserは解釈できないmark-upを無視する」という大前提があるのに、
「UAはq要素の前後を引用符でrenderしなければならず、書き手は引用符を書くべきではない」
というムチャクチャな勧告を出しているから、ややこしくなる。
「UAはq要素の前後に引用符を勝手に付け足してはならない」という勧告であれば、何の問題もなかったのに。。
HTMLは最終的に人間が読むという事実を忘れるべきではない。
だから、人間が不自然と感じるようrenderされる蓋然性のあるmark-upは避けるべき。
ただ、コード書きとしては、引用部にmark-upなされていると、活用できるのでうれしい。
が、「引用」という一つの論理要素について、二重にmark-upするのは回避すべき。
だから下記の要件を同時に満たす解決法でなければならない。
・UAが<q>を解釈できるか否かにかかわらず、一重の引用符で囲まれるべき。
・一つの論理要素に、二重にmark-up(すなわち論理意味付け)をしてはならない。
私は
彼は「<q>逝ってよし</q>」と言った
q {quotes:none;}
を推奨したい。
もっとも「q要素を勧告通り解釈できるが、quotesプロパティを解釈できない」ブラウザでは
彼は「「逝ってよし」」と言った
となってしまうが、、、そんな中途半端なブラウザがないことを祈る。(w
93 ：Name_Not_Found：01/10/13 08:17 ID:UPqJGG5M
<xml:namespace prefix="引用" />
<引用>逝ってよし</引用>
これでいいだろ。
<引用>逝ってよし</引用>
これでいいだろ。
94 ：Name_Not_Found：01/10/13 08:23 ID:f0sn5WL6
95 ：Name_Not_Found：01/10/13 15:31 ID:gQUFzmkw
>>92
責めるべきはあくまで、実装をサボってる
（あるいは「後方互換性」を盾に放置している）Microsoftでしょう。
似た例でいえば、XHTML1.1の複雑ルビでrp要素が使えないのも、
rpのような存在そのものが理念的にイレギュラーだからでしょう。
（というかXMLの要素で「内容に記号しか含んでいない」要素は相当に変です。
普通に考えてもrp要素は明らかなイレギュラー。）
rpのような存在が真に必要なら、複雑ルビでもrpが使えなければならない。
「単純ルビにrpがあるのと同様にqにもqmが必要だ」という考え方はわかるけど、
「複雑ルビにrpがないのと同様にqにはqmは必要ない」という考え方もできる。
qは単純ルビよりも複雑ルビに近い性質の要素だと、私は思います。
※念のために書いておくと、ルビそのものが物理要素なんじゃ
ないのかという指摘はなしで。
ルビは語句とそれに関連・付随する語句とを関連づける汎用の要素であって、
読み仮名だけでなく、abbrやacronymの非省略形を書き表すのにも使えます。
（abbr・acronymのtitle属性は非省略形を書き表す「ため」の属性ではない）
ルビ注釈においても、何故rubyがglossといった名前に
ならなかったかが説明されています。
最新のメジャーなブラウザでHTML4のqに対応してないのってもうWinIEだけだよ。
OperaもNetscape(6)もLynxもMacIEもiCabも対応してるのに。
つうか標準準拠モードなんてのを取り入れたんなら、
少なくともそっちでくらいはqに括弧を付けてくれて良さそうなもんだけど。
責めるべきはあくまで、実装をサボってる
（あるいは「後方互換性」を盾に放置している）Microsoftでしょう。
似た例でいえば、XHTML1.1の複雑ルビでrp要素が使えないのも、
rpのような存在そのものが理念的にイレギュラーだからでしょう。
（というかXMLの要素で「内容に記号しか含んでいない」要素は相当に変です。
普通に考えてもrp要素は明らかなイレギュラー。）
rpのような存在が真に必要なら、複雑ルビでもrpが使えなければならない。
「単純ルビにrpがあるのと同様にqにもqmが必要だ」という考え方はわかるけど、
「複雑ルビにrpがないのと同様にqにはqmは必要ない」という考え方もできる。
qは単純ルビよりも複雑ルビに近い性質の要素だと、私は思います。
※念のために書いておくと、ルビそのものが物理要素なんじゃ
ないのかという指摘はなしで。
ルビは語句とそれに関連・付随する語句とを関連づける汎用の要素であって、
読み仮名だけでなく、abbrやacronymの非省略形を書き表すのにも使えます。
（abbr・acronymのtitle属性は非省略形を書き表す「ため」の属性ではない）
ルビ注釈においても、何故rubyがglossといった名前に
ならなかったかが説明されています。
最新のメジャーなブラウザでHTML4のqに対応してないのってもうWinIEだけだよ。
OperaもNetscape(6)もLynxもMacIEもiCabも対応してるのに。
つうか標準準拠モードなんてのを取り入れたんなら、
少なくともそっちでくらいはqに括弧を付けてくれて良さそうなもんだけど。
96 ： ：01/10/13 15:35 ID:yVDKGz.Q
>91
＞なんかq要素非対応ブラウザ(要はIEね)の為に、引用部に色をつければいいんじゃないかと言っている人いますけど
、、
＞<q>を解釈できないということは、qに指定したstyleも無視してしまうので、
＞彼は<q>逝ってよし</q>と言った
＞q {color:#0088ff;}
＞としても色は変わらない。結局
少なくとも IE6 では色が変わったよ．5.5SP2 でも変わったような覚えが．
一方，q{quotes:none;} は，IE はもちろん有効にならないが，NN61，Moz ともに " が
前後に残ってしまう．q:before{content:"";} なら有効．というわけで，見え方と意味付けと
両立させるには q:before と q:after で content を指定しなければダメっぽい．
＞なんかq要素非対応ブラウザ(要はIEね)の為に、引用部に色をつければいいんじゃないかと言っている人いますけど
、、
＞<q>を解釈できないということは、qに指定したstyleも無視してしまうので、
＞彼は<q>逝ってよし</q>と言った
＞q {color:#0088ff;}
＞としても色は変わらない。結局
少なくとも IE6 では色が変わったよ．5.5SP2 でも変わったような覚えが．
一方，q{quotes:none;} は，IE はもちろん有効にならないが，NN61，Moz ともに " が
前後に残ってしまう．q:before{content:"";} なら有効．というわけで，見え方と意味付けと
両立させるには q:before と q:after で content を指定しなければダメっぽい．
97 ：Name_Not_Found：01/10/13 15:44 ID:vrlKgs2k
>>92に賛成。自然言語のテキストの儘でも問題なく読める書き方をすべき。
>>96
次の指定でもNN6で引用符挿入消しは有効でしたが。
Q {quotes:none;}
Q:before {content:open-quote;}
Q:after {content:close-quote;}
>>96
次の指定でもNN6で引用符挿入消しは有効でしたが。
Q {quotes:none;}
Q:before {content:open-quote;}
Q:after {content:close-quote;}
98 ：Name_Not_Found：01/10/13 15:49 ID:ms4iJhVg
ごめん、間違った。やはりq:before,q:after{content:"";} にしないと「"」が出ました。
100 ：Name_Not_Found：01/10/13 15:52 ID:ms4iJhVg
>自然言語のテキストの儘でも問題なく読める書き方をすべき。
というなら、「連続するスペース・改行・タブは一つの区切り文字と見なす」というXMLの仕様すら否定されてしまうと思うのですが、どうでしょうか。
というなら、「連続するスペース・改行・タブは一つの区切り文字と見なす」というXMLの仕様すら否定されてしまうと思うのですが、どうでしょうか。
101 ：Name_Not_Found：01/10/13 16:16 ID:iCWrbmzs
>>96
仕様上はquotes:noneだけで引用符の追加は無くならなければならないはずですよね。
Mozillaもまだまだ対応不十分ってことですか。
>>100
横から質問。
自然言語でも「連続するスペース・改行・タブは一つの区切り文字と見な」しませんか。
仕様上はquotes:noneだけで引用符の追加は無くならなければならないはずですよね。
Mozillaもまだまだ対応不十分ってことですか。
>>100
横から質問。
自然言語でも「連続するスペース・改行・タブは一つの区切り文字と見な」しませんか。
>>89
イラストサイトなどで、単純に画像(imgであれobjectであれ)を見せたい場合には、
pよりもdivの方が適切な場合もあると思いますが…。
ナヴィゲーションの階層表示(TOP>WORKS>CGみたいな)なども、
pよりはdivの方が適切だと思うし、
段落というのは文章に対して言うものであって、
フレーズに対して言うものではないと思います。
文章をなさないフレーズがあって、
それがタイトル/見出し/リスト項目/表項目/アドレスどれにも当てはまらないなら、
divを使うべきなんじゃないですか？
以上マジレスでした。
イラストサイトなどで、単純に画像(imgであれobjectであれ)を見せたい場合には、
pよりもdivの方が適切な場合もあると思いますが…。
ナヴィゲーションの階層表示(TOP>WORKS>CGみたいな)なども、
pよりはdivの方が適切だと思うし、
段落というのは文章に対して言うものであって、
フレーズに対して言うものではないと思います。
文章をなさないフレーズがあって、
それがタイトル/見出し/リスト項目/表項目/アドレスどれにも当てはまらないなら、
divを使うべきなんじゃないですか？
以上マジレスでした。
103 ：Name_Not_Found：01/10/13 16:28 ID:ms4iJhVg
>>101
>自然言語でも「連続するスペース・改行・タブは一つの区切り文字と見な」しませんか。
「自然言語では括弧で引用を表現するだろｺﾞﾙｧ」という言い方に対する
「自然言語では改行で新しい段落を表現するだろｺﾞﾙｧ」という言い方を想定しましたが。
>自然言語でも「連続するスペース・改行・タブは一つの区切り文字と見な」しませんか。
「自然言語では括弧で引用を表現するだろｺﾞﾙｧ」という言い方に対する
「自然言語では改行で新しい段落を表現するだろｺﾞﾙｧ」という言い方を想定しましたが。
104 ：Name_Not_Found：01/10/13 16:30 ID:lp6mQxdQ
>>101
見なさないでしょ。
改行がなきゃ段落とはみなされないし。
(天声人語みたいな改行マークでもついてりゃ別だけど)
改行使わずにHTML/XMLかいても何ら問題はない(宣言/命令除く)が、
それは自然言語では意味(見出しとか段落とか)をなさないでしょ。
見なさないでしょ。
改行がなきゃ段落とはみなされないし。
(天声人語みたいな改行マークでもついてりゃ別だけど)
改行使わずにHTML/XMLかいても何ら問題はない(宣言/命令除く)が、
それは自然言語では意味(見出しとか段落とか)をなさないでしょ。
>>102
たぶん>>89は「匿名ブロック」ができるのを嫌ってるんですよね？
cf.http://www.y-adagio.com/public/standards/tr_css2/visuren.html#anonymous-block-level
>>103-104
「区切り文字」って「段落」って意味で言ってたんですか。
「文字」と「段落」とはまた別物だと思ってました（少なくとも自然言語では）。
自然言語でスペースを連続したりタブを入れたりすればそれは区切りを意味しますけど、
xmlでの定義がどうなってるのかは知りませんので。
たぶん>>89は「匿名ブロック」ができるのを嫌ってるんですよね？
cf.http://www.y-adagio.com/public/standards/tr_css2/visuren.html#anonymous-block-level
>>103-104
「区切り文字」って「段落」って意味で言ってたんですか。
「文字」と「段落」とはまた別物だと思ってました（少なくとも自然言語では）。
自然言語でスペースを連続したりタブを入れたりすればそれは区切りを意味しますけど、
xmlでの定義がどうなってるのかは知りませんので。
>>89に対する意見として僕も>>102に同意なんだけど、
>>105の匿名ブロックボックスの指摘は違うんじゃないかな?
この場合匿名ブロックボックスは生成されないと思うんだけど。
http://www.fan.gr.jp/~kaz/rec-css2/visuren.html#anonymous-block-level
>>105の匿名ブロックボックスの指摘は違うんじゃないかな?
この場合匿名ブロックボックスは生成されないと思うんだけど。
http://www.fan.gr.jp/~kaz/rec-css2/visuren.html#anonymous-block-level
>>106
同意&フォローさんくす。
多分yuuさんは、Trasitionalでbodyやblockquoteの直下に
生のテキストを書くような気持ち悪さを感じてるんだと思うけど。
ブロック要素には「1:他のブロック要素を内容に持つブロック要素」と
「2:インライン要素を内容に持つブロック要素」があって、
divは1、2どちらとも見なせる(両者の意味を含んだ)「汎用ブロック要素」であるはず。
yuuさんは2の見方をしてくれてないんじゃないかな。
同意&フォローさんくす。
多分yuuさんは、Trasitionalでbodyやblockquoteの直下に
生のテキストを書くような気持ち悪さを感じてるんだと思うけど。
ブロック要素には「1:他のブロック要素を内容に持つブロック要素」と
「2:インライン要素を内容に持つブロック要素」があって、
divは1、2どちらとも見なせる(両者の意味を含んだ)「汎用ブロック要素」であるはず。
yuuさんは2の見方をしてくれてないんじゃないかな。
108 ：Name_Not_Found：01/10/13 19:50 ID:FYgTjNfY
>>95
>>>92
>責めるべきはあくまで、実装をサボってる
>（あるいは「後方互換性」を盾に放置している）Microsoftでしょう。
後方互換性は重要な原則ですよ。PCスペック等の事情でNN4を使っている人も多いのです。
W3Cはそういったユーザを考えなければなりません。これまでも他の要素について考慮してきたのだし、
Q要素のマークアップについて後方互換性を意識した仕様設計は簡単にできるのだから、
W3CがQ要素の前後に引用符を付け加えるようユーザエージェントに要求したのはやはり
責めるべき重大な落ち度でしょう。
IEがQを実装すべきことには同意しますが、やはりW3Cの設計上のミスを看過すべきではありません。
>>>92
>責めるべきはあくまで、実装をサボってる
>（あるいは「後方互換性」を盾に放置している）Microsoftでしょう。
後方互換性は重要な原則ですよ。PCスペック等の事情でNN4を使っている人も多いのです。
W3Cはそういったユーザを考えなければなりません。これまでも他の要素について考慮してきたのだし、
Q要素のマークアップについて後方互換性を意識した仕様設計は簡単にできるのだから、
W3CがQ要素の前後に引用符を付け加えるようユーザエージェントに要求したのはやはり
責めるべき重大な落ち度でしょう。
IEがQを実装すべきことには同意しますが、やはりW3Cの設計上のミスを看過すべきではありません。
>>108
W3Cは貧弱な環境の事は考えてると思うんだけど?
だからこそプログラム側で負担がかからないように
文法を厳しくしたり、htmlはシンプルにして
余裕があれば+cssという方向に来たと思うんだけど。
まあ後方互換という点では今回の q や tfoot など
の仕様に疑問があるが。
q より tfoot のほうが断然問題あると思わない?
W3Cは貧弱な環境の事は考えてると思うんだけど?
だからこそプログラム側で負担がかからないように
文法を厳しくしたり、htmlはシンプルにして
余裕があれば+cssという方向に来たと思うんだけど。
まあ後方互換という点では今回の q や tfoot など
の仕様に疑問があるが。
q より tfoot のほうが断然問題あると思わない?
110 ：Name_Not_Found：01/10/13 21:16 ID:vII07d6s
>>109
＞W3Cは貧弱な環境の事は考えてる
それは>>108も「これまでも他の要素について考慮してきたのだし」と断ってるのに。
その上で「後方互換という点では今回の q ……の仕様に疑問がある」ってことを
述べてるんだから、結局あなたと一緒の意見ではありませんか。
だのに、なぜあなたはわざわざ異を立てるみたいな口調で書き込むのですか？>>109
＞W3Cは貧弱な環境の事は考えてる
それは>>108も「これまでも他の要素について考慮してきたのだし」と断ってるのに。
その上で「後方互換という点では今回の q ……の仕様に疑問がある」ってことを
述べてるんだから、結局あなたと一緒の意見ではありませんか。
だのに、なぜあなたはわざわざ異を立てるみたいな口調で書き込むのですか？>>109
>>110
>PCスペック等の事情でNN4を使っている人も多いのです。
>W3Cはそういったユーザを考えなければなりません。
に対して
>W3Cは貧弱な環境の事は考えてると…
と意見を述べ、
>これまでも他の要素について考慮してきたのだし、
>Q要素のマークアップについて…
に対して
>q や tfoot などの仕様に疑問があるが…
と同意したつもりでした。
うまく伝わらなかったようですいません。
>PCスペック等の事情でNN4を使っている人も多いのです。
>W3Cはそういったユーザを考えなければなりません。
に対して
>W3Cは貧弱な環境の事は考えてると…
と意見を述べ、
>これまでも他の要素について考慮してきたのだし、
>Q要素のマークアップについて…
に対して
>q や tfoot などの仕様に疑問があるが…
と同意したつもりでした。
うまく伝わらなかったようですいません。
112 ：Name_Not_Found：01/10/13 22:15 ID:Ob.WgyRA
tfootは省略可なんだから、嫌なら無理して使う必要もあるまい。
とか思った。thead/tfoot/tbody無しで、いきなりtrから書いても一応validなんだし。
とか思った。thead/tfoot/tbody無しで、いきなりtrから書いても一応validなんだし。
113 ： ：01/10/13 23:20 ID:n9kMsKNQ
>109
あれ？前の tfoot 議論の時にいつのまにか話が消えちゃったから，
何か解決（納得）したのかと思ってたよ…．
ちなみに僕は依然として問題あると思わない．
あれ？前の tfoot 議論の時にいつのまにか話が消えちゃったから，
何か解決（納得）したのかと思ってたよ…．
ちなみに僕は依然として問題あると思わない．
114 ：Name_Not_Found：01/10/13 23:24 ID:s8DJhxPQ
>>112
そういう問題じゃないだろ。
footerはfooterとしてマークアップしたいのに、
それを解釈できないために変なところに表示してしまうUAは困る、
っていう話なんだから。
XHTMLでは元々tbodyはオプションだから、table直下にtrを書けるのは当然。
HTML4では、trから書いても問題ないのは、tbodyだけでthead/tfootが無いとき。
その場合はtbodyの開始/終了タグの省略と見なされる。
ヘッダかフッタがあるのにそれをマークアップしない、
というのはStrict的には駄目だろう。
そういう問題じゃないだろ。
footerはfooterとしてマークアップしたいのに、
それを解釈できないために変なところに表示してしまうUAは困る、
っていう話なんだから。
XHTMLでは元々tbodyはオプションだから、table直下にtrを書けるのは当然。
HTML4では、trから書いても問題ないのは、tbodyだけでthead/tfootが無いとき。
その場合はtbodyの開始/終了タグの省略と見なされる。
ヘッダかフッタがあるのにそれをマークアップしない、
というのはStrict的には駄目だろう。
>>90
URNの要件を満たす要素としてISBNを書くのがアリだとしても、
CITE要素で書名、著者名を併記するのが常識的だろうな。
>>92
>そもそもq要素自体の定義付けがルール違反なの。
>「UAはq要素の前後を引用符でrenderしなければならず、書き手は引用符を書くべきではない」
>というムチャクチャな勧告を出しているから、ややこしくなる。
>「UAはq要素の前後に引用符を勝手に付け足してはならない」という勧告であれば、何の問題もなかったのに。。
おおむね同意だが（実はRFCとか全然知らんけど）、
「勧告」は所詮「勧告」だ。それが不適切なら無視すればよい。
あの手の勧告はあくまで参考だと思っとけよ。肝心なのは仕様だし。
そもそもRFCだろうとあなたの案だろうと
「あらゆる条件下での模範解答」ではないだろ？
あなたの意見の方が明らかに妥当だとしてもな。
肝心な事は「Qは行中での引用を現す要素」という事だけだ。
勧告はどうあれ定義がルール違反ということではない。
>彼は「<q>逝ってよし</q>」と言った
>q {quotes:none;}
妥当やね。<Q></Q>は引用符をふるための記号では断じてない。
>>95
>最新のメジャーなブラウザでHTML4のqに対応してないのってもうWinIEだけだよ。
デフォルトのスタイルで見栄えに影響ないだけでちゃんと対応してるよ。
少なくともIE5.5以降はね。
スタイル指定してやりゃちゃんと反映される。
URNの要件を満たす要素としてISBNを書くのがアリだとしても、
CITE要素で書名、著者名を併記するのが常識的だろうな。
>>92
>そもそもq要素自体の定義付けがルール違反なの。
>「UAはq要素の前後を引用符でrenderしなければならず、書き手は引用符を書くべきではない」
>というムチャクチャな勧告を出しているから、ややこしくなる。
>「UAはq要素の前後に引用符を勝手に付け足してはならない」という勧告であれば、何の問題もなかったのに。。
おおむね同意だが（実はRFCとか全然知らんけど）、
「勧告」は所詮「勧告」だ。それが不適切なら無視すればよい。
あの手の勧告はあくまで参考だと思っとけよ。肝心なのは仕様だし。
そもそもRFCだろうとあなたの案だろうと
「あらゆる条件下での模範解答」ではないだろ？
あなたの意見の方が明らかに妥当だとしてもな。
肝心な事は「Qは行中での引用を現す要素」という事だけだ。
勧告はどうあれ定義がルール違反ということではない。
>彼は「<q>逝ってよし</q>」と言った
>q {quotes:none;}
妥当やね。<Q></Q>は引用符をふるための記号では断じてない。
>>95
>最新のメジャーなブラウザでHTML4のqに対応してないのってもうWinIEだけだよ。
デフォルトのスタイルで見栄えに影響ないだけでちゃんと対応してるよ。
少なくともIE5.5以降はね。
スタイル指定してやりゃちゃんと反映される。
116 ：Name_Not_Found：01/10/13 23:42 ID:p5NJOX66
WinIEのDOMでqの前後に引用符を付ける様なスクリプトって書けるかな？
117 ：Name_Not_Found：01/10/14 00:57 ID:BWGzGbec
>>105
引用句に引用符を付けてはいけない（付けない方がいい）のはおかしい、というのは、
連続する改行・タブ・半角スペースを「XMLの区切り文字」と扱い「改行としてレンダリング」してくれないのはおかしい、と言っているのと同じ次元の話ではないのですか、ということです。
>>115
>デフォルトのスタイルで見栄えに影響ないだけでちゃんと対応してるよ。
HTML4の仕様には「引用符を付けてレンダリングしなければならない」とあったので、「対応してない」と書きました。
引用句に引用符を付けてはいけない（付けない方がいい）のはおかしい、というのは、
連続する改行・タブ・半角スペースを「XMLの区切り文字」と扱い「改行としてレンダリング」してくれないのはおかしい、と言っているのと同じ次元の話ではないのですか、ということです。
>>115
>デフォルトのスタイルで見栄えに影響ないだけでちゃんと対応してるよ。
HTML4の仕様には「引用符を付けてレンダリングしなければならない」とあったので、「対応してない」と書きました。
118 ：Name_Not_Found：01/10/14 00:58 ID:BWGzGbec
117訂正。
「XMLの区切り文字」と扱い
↓
「XMLの区切り文字」として扱い
「XMLの区切り文字」と扱い
↓
「XMLの区切り文字」として扱い
>117
>HTML4の仕様には「引用符を付けてレンダリングしなければならない」とあったので、「対応してない」と書きました。
だからそれは「仕様」じゃなくて「勧告」なんでしょ？
>HTML4の仕様には「引用符を付けてレンダリングしなければならない」とあったので、「対応してない」と書きました。
だからそれは「仕様」じゃなくて「勧告」なんでしょ？
120 ：Name_Not_Found：01/10/14 02:11 ID:Mtg9.Q72
>>119
"HTML 4.01 Specification
W3C Recommendation 24 December 1999"
直訳すると「HTML4.01仕様書、W3C勧告 1999/12/24」なので、何も間違ってないと思いますけど……
勧告だから強制力を伴わない、と言いたいなら、それはその通りですけどね。
"HTML 4.01 Specification
W3C Recommendation 24 December 1999"
直訳すると「HTML4.01仕様書、W3C勧告 1999/12/24」なので、何も間違ってないと思いますけど……
勧告だから強制力を伴わない、と言いたいなら、それはその通りですけどね。
122 ：Name_Not_Found：01/10/14 05:50 ID:rdEgJz2D
論議初参戦。
>>102
imgもinlineですょ。つまり、構造上はtextと同じ。
http://www.w3.org/TR/html401/struct/global.html#h-7.5.3
わざわざdiv(=要素のグループ化)を使おうという発想に驚いた。
そんなんなら、わざわざdiv使う必要無いんじゃない？
# あ、別に、それをやめろと言ってるわけじゃないょ。
>>106
少なくとも、勧告的（ｗには合ってると思われ。
>>120
そういいたくなるのはわからんでもないが、キレちゃいかんキレちゃ。
ちなみに、>>115が言ってる仕様ってのはDTDのこととか勝手に妄想。
# 違うかな・・・。
どうでもいいけど、現実主義者VS信者みたいな図式になってるね。
>>102
imgもinlineですょ。つまり、構造上はtextと同じ。
http://www.w3.org/TR/html401/struct/global.html#h-7.5.3
わざわざdiv(=要素のグループ化)を使おうという発想に驚いた。
そんなんなら、わざわざdiv使う必要無いんじゃない？
# あ、別に、それをやめろと言ってるわけじゃないょ。
>>106
少なくとも、勧告的（ｗには合ってると思われ。
>>120
そういいたくなるのはわからんでもないが、キレちゃいかんキレちゃ。
ちなみに、>>115が言ってる仕様ってのはDTDのこととか勝手に妄想。
# 違うかな・・・。
どうでもいいけど、現実主義者VS信者みたいな図式になってるね。
123 ：yuu ◆xo3ilszg ：01/10/14 06:20 ID:WxVRFoY9
>>102
>イラストサイトなどで、単純に画像(imgであれobjectであれ)を見せたい場合には、
>pよりもdivの方が適切な場合もあると思いますが…。
imgのalt（或いはlongdescもか?）に何を書いているかに依りますが
いずれにしてもdivというのは、なんかなじまないというか、とにかく
私的には好きではないというコトです。
>ナヴィゲーションの階層表示(TOP>WORKS>CGみたいな)なども、
>pよりはdivの方が適切だと思うし
それはリストのほうが、まだしっくりきませんか。
>段落というのは文章に対して言うものであって、
>フレーズに対して言うものではないと思います。
パラグラフだとどうですか?
>文章をなさないフレーズがあって、
それをいうならセンテンスです。文章はセンテンスの集合です。
フレーズというのは言い回しとかを意味する言葉のまとまりです。
たとえば、ことわざとか格言はフレーズに相当しますが、ことわざをdivで
括りますか?
別に論点をそらしているのではなくて、パラグラフはパラグラフであると
いうことを言いたいというか、まあ、とにかく div 直下にインラインは
好きじゃないんですっ。
>イラストサイトなどで、単純に画像(imgであれobjectであれ)を見せたい場合には、
>pよりもdivの方が適切な場合もあると思いますが…。
imgのalt（或いはlongdescもか?）に何を書いているかに依りますが
いずれにしてもdivというのは、なんかなじまないというか、とにかく
私的には好きではないというコトです。
>ナヴィゲーションの階層表示(TOP>WORKS>CGみたいな)なども、
>pよりはdivの方が適切だと思うし
それはリストのほうが、まだしっくりきませんか。
>段落というのは文章に対して言うものであって、
>フレーズに対して言うものではないと思います。
パラグラフだとどうですか?
>文章をなさないフレーズがあって、
それをいうならセンテンスです。文章はセンテンスの集合です。
フレーズというのは言い回しとかを意味する言葉のまとまりです。
たとえば、ことわざとか格言はフレーズに相当しますが、ことわざをdivで
括りますか?
別に論点をそらしているのではなくて、パラグラフはパラグラフであると
いうことを言いたいというか、まあ、とにかく div 直下にインラインは
好きじゃないんですっ。
>>117
XMLでは「区切り文字」は「改行」と同じ意味なんですか？
自然言語では文字は文字であって改行ではないんですけれど。どうもよくわかりませんね。
引用符みたいな約物（記号文字）と改行を一緒にするのは無理があります（少なくとも自然言語では、ね）。
しかしきっとXMLでは話が別なのでせう。……本題からそれますね、sage。
XMLでは「区切り文字」は「改行」と同じ意味なんですか？
自然言語では文字は文字であって改行ではないんですけれど。どうもよくわかりませんね。
引用符みたいな約物（記号文字）と改行を一緒にするのは無理があります（少なくとも自然言語では、ね）。
しかしきっとXMLでは話が別なのでせう。……本題からそれますね、sage。
125 ：Name_Not_Found：01/10/14 19:04 ID:hc9HrbNW
ちょっと補足。
>>30や>>63みたいに、「」の中味は引用とは限らない、
故に引用のマークアップとしては曖昧ではないかって疑念に対して。
>鍵括弧に明確な引用という意味が無い以上、Q要素の
>代替にはならないのでは。
それでも「」はやはり立派な引用符です。
第一に、台詞や会話文を「」で括る場合。これはもちろん、
他人の発言から引用してるわけですから、引用符たる鍵括弧を使用して何の不思議もない。
第二に、強調のため「」で括る場合ですが、これも広義の引用と見なせます。
よくある例では、普通と異なった意味において或る言葉を使用する時に「」で括ります。
強調の鍵括弧で括られたＸは、世に所謂「Ｘ」、といった意味を持つからです。
特に「」で括ることによって、語の意味概念（シニフィエ）ではなく
表面的な記号表現（シニフィアン）を対象とすることを示し得るわけです。
鍵括弧がつけられると、その中味は既にどこかにある言葉を持ってきたことが強調されるのです。
これはつまり、広い意味での引用と言ってよい。
台詞や会話文と違って発言者（引用元）こそ特定されないものの、
世間の一般的な言説や匿名の顔無き他者（複数）からの漠然たる引用として
「」で括られるのではないか。
HTMLってよりはこれも自然言語の表記に関する考察ですのでsage。
>>30や>>63みたいに、「」の中味は引用とは限らない、
故に引用のマークアップとしては曖昧ではないかって疑念に対して。
>鍵括弧に明確な引用という意味が無い以上、Q要素の
>代替にはならないのでは。
それでも「」はやはり立派な引用符です。
第一に、台詞や会話文を「」で括る場合。これはもちろん、
他人の発言から引用してるわけですから、引用符たる鍵括弧を使用して何の不思議もない。
第二に、強調のため「」で括る場合ですが、これも広義の引用と見なせます。
よくある例では、普通と異なった意味において或る言葉を使用する時に「」で括ります。
強調の鍵括弧で括られたＸは、世に所謂「Ｘ」、といった意味を持つからです。
特に「」で括ることによって、語の意味概念（シニフィエ）ではなく
表面的な記号表現（シニフィアン）を対象とすることを示し得るわけです。
鍵括弧がつけられると、その中味は既にどこかにある言葉を持ってきたことが強調されるのです。
これはつまり、広い意味での引用と言ってよい。
台詞や会話文と違って発言者（引用元）こそ特定されないものの、
世間の一般的な言説や匿名の顔無き他者（複数）からの漠然たる引用として
「」で括られるのではないか。
HTMLってよりはこれも自然言語の表記に関する考察ですのでsage。
126 ：Name_Not_Found：01/10/14 20:05 ID:JLNdSd9t
>>125
単に強調の為に「」で括るのを広義の引用とみなせるというのは、
どこから引用したと認識するの?
台詞や会話文を「」で括るのを引用だと判断するのは、
脚本などでも気になるが、小説での台詞部分を「」で括ったのを
引用だとするのはおかしくないか?
自ら創作したものでさえ引用と認識するのか?
大辞林なんかを見ても、鉤括弧が引用の為にあると認識するのは難しいな。
単に強調の為に「」で括るのを広義の引用とみなせるというのは、
どこから引用したと認識するの?
台詞や会話文を「」で括るのを引用だと判断するのは、
脚本などでも気になるが、小説での台詞部分を「」で括ったのを
引用だとするのはおかしくないか?
自ら創作したものでさえ引用と認識するのか?
大辞林なんかを見ても、鉤括弧が引用の為にあると認識するのは難しいな。
>>122
いや、だから言ってるんです。body直下にimg書けないでしょ。
altを文章の一部にできるならpの内容にすればいいけど。
>>123
例えばCGギャラリーみたいなページだと、
・絵のタイトル
・絵
・絵の解説
みたいな構成になってることが多いと思います。
全体をtableにしちゃうとか、
定義リストにするとか言った方法もありますが(この方が自然かな…)、
場合によってはh1/div/pにした方が良いこともあるんじゃないかって事です。
勿論altをどう記述するかにもよりますが。
ナヴィゲーションに関しては僕自身、
「top|index|prev|next」みたいなのは明らかにリストだから、
li{display:inline;}にでもした方がいいと思うと言ったことがあります。
ただ、完全に階層表示になってる場合はあながちリストとは言えないと思うので。
yuuさんはbody内部の文章の断片が、
全てh?/p/address/td/th/li/dt/dd/などの非汎用要素だけで表せるとお考えですか？
だとしたらstrictでもdiv直下に生のテキストが存在しうる理由って何なのでしょうか。
いや、だから言ってるんです。body直下にimg書けないでしょ。
altを文章の一部にできるならpの内容にすればいいけど。
>>123
例えばCGギャラリーみたいなページだと、
・絵のタイトル
・絵
・絵の解説
みたいな構成になってることが多いと思います。
全体をtableにしちゃうとか、
定義リストにするとか言った方法もありますが(この方が自然かな…)、
場合によってはh1/div/pにした方が良いこともあるんじゃないかって事です。
勿論altをどう記述するかにもよりますが。
ナヴィゲーションに関しては僕自身、
「top|index|prev|next」みたいなのは明らかにリストだから、
li{display:inline;}にでもした方がいいと思うと言ったことがあります。
ただ、完全に階層表示になってる場合はあながちリストとは言えないと思うので。
yuuさんはbody内部の文章の断片が、
全てh?/p/address/td/th/li/dt/dd/などの非汎用要素だけで表せるとお考えですか？
だとしたらstrictでもdiv直下に生のテキストが存在しうる理由って何なのでしょうか。
>>126
>どこから引用したと認識するの?
既に>>125で述べました。どこからとも特定されない一般多数から、です。
>自ら創作したものでさえ引用と認識するのか?
創作の中の台詞であれ、それはそこに仮設された登場人物の生の発言から
抜き取って紙の上に引用したものであるはず。
但しこれらは、もちろん普段は所謂「引用」とは意識されない。
しかしカギカッコの様々な用法に共通する本質を抽出して考察するなら、
「」内は広義の引用と見なすのが最も当を得てるのではってことです。
>どこから引用したと認識するの?
既に>>125で述べました。どこからとも特定されない一般多数から、です。
>自ら創作したものでさえ引用と認識するのか?
創作の中の台詞であれ、それはそこに仮設された登場人物の生の発言から
抜き取って紙の上に引用したものであるはず。
但しこれらは、もちろん普段は所謂「引用」とは意識されない。
しかしカギカッコの様々な用法に共通する本質を抽出して考察するなら、
「」内は広義の引用と見なすのが最も当を得てるのではってことです。
129 ：Name_Not_Found：01/10/14 22:41 ID:1nI+bG2n
仮に「」がその広義の引用であったとして、それが通用するのは日本。
W3Cは日本のことだけを考えているのではないってことです。
W3Cは日本のことだけを考えているのではないってことです。
130 ：Name_Not_Found：01/10/14 23:03 ID:NOV1arfC
>>129
??? 「W3Cは日本のことだけを考えているのではない」って、
――当り前です。
事実quotesプロパティでは初期値「" "」だけど、
これは各言語に適した引用符に置換できますよね。
そして日本語の場合の引用符は「」であるってだけのこと。
しかし「」を日本語の引用記号と見なすことに異論があったので、
それへの反駁が>>125でしょ？
??? 「W3Cは日本のことだけを考えているのではない」って、
――当り前です。
事実quotesプロパティでは初期値「" "」だけど、
これは各言語に適した引用符に置換できますよね。
そして日本語の場合の引用符は「」であるってだけのこと。
しかし「」を日本語の引用記号と見なすことに異論があったので、
それへの反駁が>>125でしょ？
131 ：95=117=121：01/10/14 23:22 ID:pxh8J/rG
>>124
えとですね。
・プレーンテキストでは引用符で引用句を表現する。
・「引用符」は引用句要素のタグではない。
→引用符を引用句要素のタグとして扱わずにわざわざq要素なんてものを定義しているHTML4は糞
→後方互換性を考えたらq要素は不可
ここまでの「W3Cの方針に対する批判」は私にはこのような事を言っているものと解釈できました。
で、それなら「
・プレーンテキストでは連続する改行で段落を表現する。
・「連続する改行」（＝「XMLの区切り子」）は（改行としてはレンダリングされないし、まして）段落要素のタグではない。
→連続する改行を段落要素のタグとして扱わずにわざわざp要素なんてものを定義しているHTML4は糞
→後方互換性を考えたらp要素は不可
ということも何故言ってみないのですか、
q要素への批判はこれと同じくらいナンセンスな話ではないのですか、
引用符のことはこれだけ長々と文句を言うくせに、何故、改行文字の扱いには黙々と従うのですか」
ということが言いたかったのです。
私は改行も引用符も同じ記号文字だと考えていますから、
「この二つは全然別の話であって、後者の問題は容認できても前者の問題は容認できない」
というのは矛盾している、と思った次第です。
えとですね。
・プレーンテキストでは引用符で引用句を表現する。
・「引用符」は引用句要素のタグではない。
→引用符を引用句要素のタグとして扱わずにわざわざq要素なんてものを定義しているHTML4は糞
→後方互換性を考えたらq要素は不可
ここまでの「W3Cの方針に対する批判」は私にはこのような事を言っているものと解釈できました。
で、それなら「
・プレーンテキストでは連続する改行で段落を表現する。
・「連続する改行」（＝「XMLの区切り子」）は（改行としてはレンダリングされないし、まして）段落要素のタグではない。
→連続する改行を段落要素のタグとして扱わずにわざわざp要素なんてものを定義しているHTML4は糞
→後方互換性を考えたらp要素は不可
ということも何故言ってみないのですか、
q要素への批判はこれと同じくらいナンセンスな話ではないのですか、
引用符のことはこれだけ長々と文句を言うくせに、何故、改行文字の扱いには黙々と従うのですか」
ということが言いたかったのです。
私は改行も引用符も同じ記号文字だと考えていますから、
「この二つは全然別の話であって、後者の問題は容認できても前者の問題は容認できない」
というのは矛盾している、と思った次第です。
>>131
＞私は改行も引用符も同じ記号文字だと考えていますから、
きっとパソコンが得意でコンピューターライクな思考をしてる方なんですね。
やっとわかったのですが、そもそも“改行「文字」"ってのがコンピュータ向けの思考法なんだなと。
自然言語では改行って概念はあっても、普通それは「文字」として記号化されてません。
私はモニターの中よりも紙の上にある文字の方を相手にすることが多い仕事なんで、
コンピューター式の改行概念には馴染めず、活字組版を基本にして把握する傾向があります。
自然言語寄りの見地に立つと、引用符みたいに目に見えてる文字記号と
改行みたいに目に見える文字の形を取らない概念とは別物で、一緒にできないんです。
＞私は改行も引用符も同じ記号文字だと考えていますから、
きっとパソコンが得意でコンピューターライクな思考をしてる方なんですね。
やっとわかったのですが、そもそも“改行「文字」"ってのがコンピュータ向けの思考法なんだなと。
自然言語では改行って概念はあっても、普通それは「文字」として記号化されてません。
私はモニターの中よりも紙の上にある文字の方を相手にすることが多い仕事なんで、
コンピューター式の改行概念には馴染めず、活字組版を基本にして把握する傾向があります。
自然言語寄りの見地に立つと、引用符みたいに目に見えてる文字記号と
改行みたいに目に見える文字の形を取らない概念とは別物で、一緒にできないんです。
133 ：95=117=121：01/10/15 00:15 ID:BtPd77cM
>>120,121
W3Cの仕様書にレンダリングや用法の手引きが付記されている意図は充分理解できるし、
それは尊重される事が望ましいとは思うが
IEがQ要素「未対応」とか「仕様から外れている」って言うのは違うんじゃないの？
あれを未対応つーなら本当にQを認識しないブラウザと同じだとでも言う気か？
「勧告」はしょせん「勧告」だし、「スタイル」はしょせん「スタイル」だ。「要素」じゃないだろ？
それをHTMLの「仕様の実体」だと言うのなら、そんなの「論理マークアップ言語」だなんて言えるのか？
W3Cだって伊達や酔狂で「勧告」という言葉を使ってるわけじゃないだろうよ。
>>122
仕様の根拠はDTDだと思ってるけど、べつに見たわけじゃないよ。
SGMLなんか解らんし。
W3Cの仕様書にレンダリングや用法の手引きが付記されている意図は充分理解できるし、
それは尊重される事が望ましいとは思うが
IEがQ要素「未対応」とか「仕様から外れている」って言うのは違うんじゃないの？
あれを未対応つーなら本当にQを認識しないブラウザと同じだとでも言う気か？
「勧告」はしょせん「勧告」だし、「スタイル」はしょせん「スタイル」だ。「要素」じゃないだろ？
それをHTMLの「仕様の実体」だと言うのなら、そんなの「論理マークアップ言語」だなんて言えるのか？
W3Cだって伊達や酔狂で「勧告」という言葉を使ってるわけじゃないだろうよ。
>>122
仕様の根拠はDTDだと思ってるけど、べつに見たわけじゃないよ。
SGMLなんか解らんし。
135 ：Name_Not_Found：01/10/15 00:46 ID:61iVxwXg
>>127
altの内容によって、どうこうっちゅうのは本末転倒な気が。
そもそも、その画像の持ってる意味が大事なんじゃ？
代替はあくまで代替。それに意味があるわけじゃない。
その例だったとしてもimg要素がテキストレベル
の要素であることには変わりはないし、
h1/div/pとかにする意義(意味)もメリットも見えてこない。
>>128
漏れには、それを引用と言うのはこじつけに聞こえるよ。
じゃあ、「」をつけないで普通にこうやって文章を書いてるのは
国語辞書からの引用なのかって、そんなことはないわけ。
＞本質を抽出して考察
させたいのならem要素のほうが適当かと。
勿論、「HTMLで」のはなしだが。
# あ、ここではマークアップできないから「」で許して。（ｗ
引用ってのは、特定の場所から引っ張ってくるから
引ぱってきて、用いると言えるものだと、漏れはおもってるんだが。
>>134
だから、君の言う仕様って何さ。
そこに答えないと話が進まんよ。
altの内容によって、どうこうっちゅうのは本末転倒な気が。
そもそも、その画像の持ってる意味が大事なんじゃ？
代替はあくまで代替。それに意味があるわけじゃない。
その例だったとしてもimg要素がテキストレベル
の要素であることには変わりはないし、
h1/div/pとかにする意義(意味)もメリットも見えてこない。
>>128
漏れには、それを引用と言うのはこじつけに聞こえるよ。
じゃあ、「」をつけないで普通にこうやって文章を書いてるのは
国語辞書からの引用なのかって、そんなことはないわけ。
＞本質を抽出して考察
させたいのならem要素のほうが適当かと。
勿論、「HTMLで」のはなしだが。
# あ、ここではマークアップできないから「」で許して。（ｗ
引用ってのは、特定の場所から引っ張ってくるから
引ぱってきて、用いると言えるものだと、漏れはおもってるんだが。
>>134
だから、君の言う仕様って何さ。
そこに答えないと話が進まんよ。
>>134
WinIE5/6はq非対応だよ。Navigator4.xとどこが違う。
せめてciteへとべるってのなら話は別だが。
ブラウザが要素を解釈するってのは整形だけの話じゃないだろ。
a要素のhrefへ跳べないブラウザがあっても、スタイル適用できれば対応してるってか。
一つ質問だが、Mozillaってrubyに対応してると思う？
WinIE5/6はq非対応だよ。Navigator4.xとどこが違う。
せめてciteへとべるってのなら話は別だが。
ブラウザが要素を解釈するってのは整形だけの話じゃないだろ。
a要素のhrefへ跳べないブラウザがあっても、スタイル適用できれば対応してるってか。
一つ質問だが、Mozillaってrubyに対応してると思う？
>>135
逆。objectを基準に考えた方が話が分かりよいと思うけど、
テキストがあって初めてimg要素が存在できる。
だからバーナーズ=リーは画像要素を空要素にしようなんて思わなかったし、
Netscapeがつくった頭の悪い空要素が採用されてもaltは必須。
altは別に音声UAとかテキストベースブラウザの為の指定ではない。
というか君はどういうalt書いてimgを何の内容にしてるの？
逆。objectを基準に考えた方が話が分かりよいと思うけど、
テキストがあって初めてimg要素が存在できる。
だからバーナーズ=リーは画像要素を空要素にしようなんて思わなかったし、
Netscapeがつくった頭の悪い空要素が採用されてもaltは必須。
altは別に音声UAとかテキストベースブラウザの為の指定ではない。
というか君はどういうalt書いてimgを何の内容にしてるの？
>>135
ナゼem要素が出てくるのかワカリマセン。
>>128は「本質を抽出して考察させたい」なんて言ってませんし（「」の本質を考察するならば、と言ってる）。
何か誤読してませんか。
ところで引用とは、逆から換言すれば、自分の言葉ではない（他人の）言葉ってことですよね。
極端な話、おっしゃる通り、他人と語彙を共有する以上は普段の文章も全て既存の語句からの
「引用」ならざるはないんですが、平生はそれは無視してよいし、しなくては話が進まない。
但し、特にこれは自分の言葉でないって断りたいときには「」で括るわけで。
自分の言葉で無ければ他人の言葉から取ってきたもののはずですが、その他人が
必ずしも特定されず、誰でもいい誰かであることは別に珍しくもないのでは？
出典は忘れたけど誰かの言葉を引いて説明するってこともありますよね？
詠み人知らずの名文句だってありますし、諺なんかその最たるもの。
ごめんなさい、言語学板の住人なものでツイ話題がそれました。
ナゼem要素が出てくるのかワカリマセン。
>>128は「本質を抽出して考察させたい」なんて言ってませんし（「」の本質を考察するならば、と言ってる）。
何か誤読してませんか。
ところで引用とは、逆から換言すれば、自分の言葉ではない（他人の）言葉ってことですよね。
極端な話、おっしゃる通り、他人と語彙を共有する以上は普段の文章も全て既存の語句からの
「引用」ならざるはないんですが、平生はそれは無視してよいし、しなくては話が進まない。
但し、特にこれは自分の言葉でないって断りたいときには「」で括るわけで。
自分の言葉で無ければ他人の言葉から取ってきたもののはずですが、その他人が
必ずしも特定されず、誰でもいい誰かであることは別に珍しくもないのでは？
出典は忘れたけど誰かの言葉を引いて説明するってこともありますよね？
詠み人知らずの名文句だってありますし、諺なんかその最たるもの。
ごめんなさい、言語学板の住人なものでツイ話題がそれました。
>>137
Piro 氏の Mozilla 用コンテキストメニュー拡張で、inline table + DOM で
見事に単純/複雑ルビ注釈をレンダリングしてしまっているので、
これが Mozilla にそのまま実装されたら完全対応と言い切れると思う。
現状では、拡張次第で完全実装可能というレベルか。
ruby 要素としてマークアップされている事をしっかり認識はしている。
IE の場合は abbr 要素としてマークアップしても完全に無視し、CSS の
指定を受け付けないのとは訳が違う。
>>139
だから、自ら創造した文章を強調表現したい場合などに「」と記述したら
それが引用だと見なせる理由になってない。
小説などの登場人物の台詞が「自らの思考内で完全に解決して」いても、
それを発言する仮想人格の言葉からの「引用」だなんてことを誰が認識できるのか。
出典を忘れた誰かの言葉を引用するのであれば、それこそ cite 属性を
指定せずに blockquote 要素や q 要素としてマークアップしたら良いだけの話。
自然言語で「話す」時に誰かの言葉を引用する際に「かぎかっこ」何て言うか?
自然言語で「書く」時に、「鉤括弧」によって人間が認識できる形で
「マークアップ」しているだけだろう。
だったら、自然言語で書かれた文章を HTML によってマークアップして
「機械に理解させる」データ形式に落とす段階では、
引用のための「」は q 要素や blockquote 要素に置き換えたら良いし、
強調のための「」は em 要素や strong 要素に置き換えたらいい。
HTML は所詮、コンピュータが解釈しやすい形に文章をマークアップする為のものであって、
その結果を人間が「視る」為のものではない。
人間が結果を入手する一形態として「見る」という方法があるのであって、
読み上げブラウザなどで「」が「かぎかっこ」などと読み上げられる事よりも、
むしろ CSS で引用符として「」を表示する方向を考えるべき。
絶対多数の IE で実装されていないからそう考えるのは避けるべきと
考えるよりも、むしろ強力に Microsoft に要望を叩き付け続け、
IE に実装されるように働き掛ける方が有意義ではないのか?
Piro 氏の Mozilla 用コンテキストメニュー拡張で、inline table + DOM で
見事に単純/複雑ルビ注釈をレンダリングしてしまっているので、
これが Mozilla にそのまま実装されたら完全対応と言い切れると思う。
現状では、拡張次第で完全実装可能というレベルか。
ruby 要素としてマークアップされている事をしっかり認識はしている。
IE の場合は abbr 要素としてマークアップしても完全に無視し、CSS の
指定を受け付けないのとは訳が違う。
>>139
だから、自ら創造した文章を強調表現したい場合などに「」と記述したら
それが引用だと見なせる理由になってない。
小説などの登場人物の台詞が「自らの思考内で完全に解決して」いても、
それを発言する仮想人格の言葉からの「引用」だなんてことを誰が認識できるのか。
出典を忘れた誰かの言葉を引用するのであれば、それこそ cite 属性を
指定せずに blockquote 要素や q 要素としてマークアップしたら良いだけの話。
自然言語で「話す」時に誰かの言葉を引用する際に「かぎかっこ」何て言うか?
自然言語で「書く」時に、「鉤括弧」によって人間が認識できる形で
「マークアップ」しているだけだろう。
だったら、自然言語で書かれた文章を HTML によってマークアップして
「機械に理解させる」データ形式に落とす段階では、
引用のための「」は q 要素や blockquote 要素に置き換えたら良いし、
強調のための「」は em 要素や strong 要素に置き換えたらいい。
HTML は所詮、コンピュータが解釈しやすい形に文章をマークアップする為のものであって、
その結果を人間が「視る」為のものではない。
人間が結果を入手する一形態として「見る」という方法があるのであって、
読み上げブラウザなどで「」が「かぎかっこ」などと読み上げられる事よりも、
むしろ CSS で引用符として「」を表示する方向を考えるべき。
絶対多数の IE で実装されていないからそう考えるのは避けるべきと
考えるよりも、むしろ強力に Microsoft に要望を叩き付け続け、
IE に実装されるように働き掛ける方が有意義ではないのか?
>>139
引用の対象には過去の自分の発言も含みますね。念のため。
過去の自分は他人って事ですが。
>>140
WinIEにせよMozniせよ、不明な要素に対してもスタイルを適用できるだけのこと。
それは、rubyに対応してるんじゃなくてCSSに対応してると言う。
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN">
<html>
<head>
<title>sample</title>
<style type="text/css">
foo{color:white;background-color:black;}
</style>
<head>
<body>
<foo>hoge</foo>
</body>
</html>
これでもfooへのスタイルは適用されるし(この実装が正しいんでしょ)。
ruby自体の持つ意味を「開発者」が理解してなければ対応とは言えない。
Piro氏のコンテキストメニュー拡張(inline-tableは北村氏ね)は、
rubyに対応してると言えるが。
それに、完全実装って言葉は微妙だと思う。何を以て完全とするのか。
それぞれの要素には色々な解釈や実装の仕方があると思う。
それは制作者の好きずきでしょ。
例えばiCabにはHeddingを抜き出して表示する機能があるけど、
それが無くともh1への対応が不完全だとは言われないし。
話は変わるけど、ブラウザがqに引用符を付ける仕様は漏れも不合理だと思う。
W3Cの人間は間接話法を知らないのだろうか。
ただ、仕様がそうと決まってしまったならUAはそう実装するしかないし、
制作者もqには引用符が付くと思って記述すべきだ。
よってWinIEはさっさと実装すべし。
# どうでもいいが、この仕様でNN4.xが駆逐される事を期待するのは無理っぽい(w
引用の対象には過去の自分の発言も含みますね。念のため。
過去の自分は他人って事ですが。
>>140
WinIEにせよMozniせよ、不明な要素に対してもスタイルを適用できるだけのこと。
それは、rubyに対応してるんじゃなくてCSSに対応してると言う。
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN">
<html>
<head>
<title>sample</title>
<style type="text/css">
foo{color:white;background-color:black;}
</style>
<head>
<body>
<foo>hoge</foo>
</body>
</html>
これでもfooへのスタイルは適用されるし(この実装が正しいんでしょ)。
ruby自体の持つ意味を「開発者」が理解してなければ対応とは言えない。
Piro氏のコンテキストメニュー拡張(inline-tableは北村氏ね)は、
rubyに対応してると言えるが。
それに、完全実装って言葉は微妙だと思う。何を以て完全とするのか。
それぞれの要素には色々な解釈や実装の仕方があると思う。
それは制作者の好きずきでしょ。
例えばiCabにはHeddingを抜き出して表示する機能があるけど、
それが無くともh1への対応が不完全だとは言われないし。
話は変わるけど、ブラウザがqに引用符を付ける仕様は漏れも不合理だと思う。
W3Cの人間は間接話法を知らないのだろうか。
ただ、仕様がそうと決まってしまったならUAはそう実装するしかないし、
制作者もqには引用符が付くと思って記述すべきだ。
よってWinIEはさっさと実装すべし。
# どうでもいいが、この仕様でNN4.xが駆逐される事を期待するのは無理っぽい(w
>>138
そんな背景があったとは。
でも、
＞テキストがあって初めてimg要素が存在できる。
ってのは、あるテキストが存在してその表現の
代わりに画像を使うというような意味ですか？
それならばなおのこと、元々がテキストなのならば
p要素でいいんじゃないかと思うんだが、どう？
>>139
＞本質を抽出して考察
ってのは確かに誤読だった・・・。スマソ。
でもどっちにしろ>>140が言ってくれてるように、
＞引用のための「」は q 要素や blockquote 要素に置き換えたら良いし、
＞強調のための「」は em 要素や strong 要素に置き換えたらいい。
と思う。
ってか、
>>102
＞間接話法
がどうかしたの？
そんな背景があったとは。
でも、
＞テキストがあって初めてimg要素が存在できる。
ってのは、あるテキストが存在してその表現の
代わりに画像を使うというような意味ですか？
それならばなおのこと、元々がテキストなのならば
p要素でいいんじゃないかと思うんだが、どう？
>>139
＞本質を抽出して考察
ってのは確かに誤読だった・・・。スマソ。
でもどっちにしろ>>140が言ってくれてるように、
＞引用のための「」は q 要素や blockquote 要素に置き換えたら良いし、
＞強調のための「」は em 要素や strong 要素に置き換えたらいい。
と思う。
ってか、
>>102
＞間接話法
がどうかしたの？
143 ：84：01/10/15 04:07 ID:22b/bVk8
>>141
多分誤読していると思うのだけど、北村氏 + Piro 氏の手による
ruby 要素に対する拡張実装と同等の物が Mozilla 標準で完全実装されると
いうのは、現在 Piro 氏がスクリプトで処理させているものを
Mozilla がレンダリングを行う際にネイティブに処理することであり、
それは Mozilla が正しく単純/複雑ルビ注釈に対して行うべき処理を
理解している前提で行われるものだと思う。
もちろんルビとはどういうものかではなく、ルビとはどのように
レンダリングされたらいいのか、という事を理解している、という意味で。
>>140 で
> ruby 要素としてマークアップされている事をしっかり認識はしている。
と書いたのは、Mozilla が HTML を解析処理する段階で、閉じタグの省略を
補完するなどした補正処理を行ってからドキュメントツリーを構成する段階で
ruby という要素を認識している、という話。
foo などの任意の要素に対してスタイルシートを指定できるのは
XML/XHTML での任意の要素定義に対する実装をそのまま
あらゆる HTML のバージョンに対しても行っているからだと思われる。
やろうと思えば、Mozilla で marquee 要素を強引に実装することもできそう。
個人的には指定された公開識別子から認識できる DTD のバージョンで
定義されている要素群か、システム識別子で読み込み指定された DTD で定義された
要素群以外にはスタイルの適用もして欲しくない気もするが。
あと、
> WinIEにせよMozniせよ、不明な要素に対してもスタイルを適用できるだけのこと。
だけど、WinIE は不明な要素に対してはスタイルを適用できない。
> IE の場合は abbr 要素としてマークアップしても完全に無視し、CSS の
> 指定を受け付けないのとは訳が違う。
と書いている通り HTML 4 spec. で定義されている abbr 要素に対して
デフォルトスタイルシートの指定が無いどころか、要素としてさえ認識していない。
多分誤読していると思うのだけど、北村氏 + Piro 氏の手による
ruby 要素に対する拡張実装と同等の物が Mozilla 標準で完全実装されると
いうのは、現在 Piro 氏がスクリプトで処理させているものを
Mozilla がレンダリングを行う際にネイティブに処理することであり、
それは Mozilla が正しく単純/複雑ルビ注釈に対して行うべき処理を
理解している前提で行われるものだと思う。
もちろんルビとはどういうものかではなく、ルビとはどのように
レンダリングされたらいいのか、という事を理解している、という意味で。
>>140 で
> ruby 要素としてマークアップされている事をしっかり認識はしている。
と書いたのは、Mozilla が HTML を解析処理する段階で、閉じタグの省略を
補完するなどした補正処理を行ってからドキュメントツリーを構成する段階で
ruby という要素を認識している、という話。
foo などの任意の要素に対してスタイルシートを指定できるのは
XML/XHTML での任意の要素定義に対する実装をそのまま
あらゆる HTML のバージョンに対しても行っているからだと思われる。
やろうと思えば、Mozilla で marquee 要素を強引に実装することもできそう。
個人的には指定された公開識別子から認識できる DTD のバージョンで
定義されている要素群か、システム識別子で読み込み指定された DTD で定義された
要素群以外にはスタイルの適用もして欲しくない気もするが。
あと、
> WinIEにせよMozniせよ、不明な要素に対してもスタイルを適用できるだけのこと。
だけど、WinIE は不明な要素に対してはスタイルを適用できない。
> IE の場合は abbr 要素としてマークアップしても完全に無視し、CSS の
> 指定を受け付けないのとは訳が違う。
と書いている通り HTML 4 spec. で定義されている abbr 要素に対して
デフォルトスタイルシートの指定が無いどころか、要素としてさえ認識していない。
145 ：Name_Not_Found：01/10/15 08:44 ID:IcODvQnU
>>140
>だから、自ら創造した文章を強調表現したい場合などに「」と記述したら
>それが引用だと見なせる理由になってない。
それだって>>141も補足した通り、過去からの引用でしょ。
既往の発言を「」で括ればそれは、あのときああ言ったあの意味で言ってるんだよ、
って意味が込められる。過去のその発言の文脈への参照を求めてるわけです。
>小説などの登場人物の台詞が「自らの思考内で完全に解決して」いても
完全なる自己完結だったらそもそも文章にも記されない。過去の脳内発言を
テキストに筆記した時点でそれは転写であり引用です。
かぎ［鉤］２.引用語を包む、鉤の形の記号。「」。（『新明解国語辞典』第三版）
したがって「」による強調も、やはり「」の引用符としての機能の拡張では？
>だから、自ら創造した文章を強調表現したい場合などに「」と記述したら
>それが引用だと見なせる理由になってない。
それだって>>141も補足した通り、過去からの引用でしょ。
既往の発言を「」で括ればそれは、あのときああ言ったあの意味で言ってるんだよ、
って意味が込められる。過去のその発言の文脈への参照を求めてるわけです。
>小説などの登場人物の台詞が「自らの思考内で完全に解決して」いても
完全なる自己完結だったらそもそも文章にも記されない。過去の脳内発言を
テキストに筆記した時点でそれは転写であり引用です。
かぎ［鉤］２.引用語を包む、鉤の形の記号。「」。（『新明解国語辞典』第三版）
したがって「」による強調も、やはり「」の引用符としての機能の拡張では？
146 ：Name_Not_Found：01/10/15 09:48 ID:6jThUJmd
これを使ったらＩＥでも一応q要素の引用符・引用元表示ができるけど。
ttp://www.remus.dti.ne.jp/~a-satomi/bunsyorou/MacIE5_benriSet.html#show-quote
さてこれでＩＥはQ要素に「対応」してることになるのか、どうか。
ttp://www.remus.dti.ne.jp/~a-satomi/bunsyorou/MacIE5_benriSet.html#show-quote
さてこれでＩＥはQ要素に「対応」してることになるのか、どうか。
147 ：84：01/10/15 10:08 ID:sfTwEo2y
>>145
■［鉤括弧］の大辞林第二版からの検索結果
かぎかっこ―くわつこ【鉤括弧】
文章表記に用いる括弧の一種。「」や『』のように鉤の手に曲がっているもの。
会話や、特に注意すべき語句を示すのに用いる。
辞書編纂者の見解の違いもありそうだけど。
その理論では「」で括られていない部分も過去からの引用に含まれるんだよ。
>>139 で書かれている通り
> 極端な話、おっしゃる通り、他人と語彙を共有する以上は普段の文章も全て既存の語句からの
> 「引用」ならざるはないんですが、平生はそれは無視してよいし、しなくては話が進まない。
な訳で、自らが創造した文章を強調する目的で鉤括弧で括った部分を
引用と認識するような人はいないよ、という事。
通常、書き手にも読み手にもね。
従って、>>145 にある
> 完全なる自己完結だったらそもそも文章にも記されない。過去の脳内発言を
> テキストに筆記した時点でそれは転写であり引用です。
というのは既に分かりきっていて、
> 「引用」ならざるはないんですが、平生はそれは無視してよいし、しなくては話が進まない。
のだから、それは無視すべき。
そうでないのであれば、全ての文章を『』で括らないとその主張は成り立たない。
脳内発言に限らず、文章を組み立てて文字化した時点でそれは引用なのだから、
body 要素直下の要素は <blockquote cite="俺の脳"> 一つということになる。
それが、君が望む引用なのか?
■［鉤括弧］の大辞林第二版からの検索結果
かぎかっこ―くわつこ【鉤括弧】
文章表記に用いる括弧の一種。「」や『』のように鉤の手に曲がっているもの。
会話や、特に注意すべき語句を示すのに用いる。
辞書編纂者の見解の違いもありそうだけど。
その理論では「」で括られていない部分も過去からの引用に含まれるんだよ。
>>139 で書かれている通り
> 極端な話、おっしゃる通り、他人と語彙を共有する以上は普段の文章も全て既存の語句からの
> 「引用」ならざるはないんですが、平生はそれは無視してよいし、しなくては話が進まない。
な訳で、自らが創造した文章を強調する目的で鉤括弧で括った部分を
引用と認識するような人はいないよ、という事。
通常、書き手にも読み手にもね。
従って、>>145 にある
> 完全なる自己完結だったらそもそも文章にも記されない。過去の脳内発言を
> テキストに筆記した時点でそれは転写であり引用です。
というのは既に分かりきっていて、
> 「引用」ならざるはないんですが、平生はそれは無視してよいし、しなくては話が進まない。
のだから、それは無視すべき。
そうでないのであれば、全ての文章を『』で括らないとその主張は成り立たない。
脳内発言に限らず、文章を組み立てて文字化した時点でそれは引用なのだから、
body 要素直下の要素は <blockquote cite="俺の脳"> 一つということになる。
それが、君が望む引用なのか?
ついでに。
かっこ[括弧]...「――付き〔＝勝義のそれであるかどうかに疑問が有り、「謂う所の」の意で引用する語〕」
（『新明解国語辞典』第三版）
いんよう 【引用符】文中で、他からの引用であることを示す符号。和文では「」『』、...
（『広辞苑』第四版）
ご参考まで。
かっこ[括弧]...「――付き〔＝勝義のそれであるかどうかに疑問が有り、「謂う所の」の意で引用する語〕」
（『新明解国語辞典』第三版）
いんよう 【引用符】文中で、他からの引用であることを示す符号。和文では「」『』、...
（『広辞苑』第四版）
ご参考まで。
150 ：( ´_ゝ｀)：01/10/15 14:38 ID:cJnkOLkh
1は既にいないと思はれ。
151 ：Name_Not_Found：01/10/15 16:44 ID:oqb+USi+
もう一つブラウザの実装とアクセシビリティの話なんだけど、
WCAGの中にolに関する記述があって、曰く
読み上げブラウザで読ませると単なるolの入れ子関係が掴めなくなる。
っていうんだけど、例を挙げると
<ol>
<li>あ
<ol><li>い</li><li>う</li></ol>
</li>
<li>か
<ol><li>き</li><li>く</li></ol>
</li>
</ol>
これを読ませると
「いち、あ、いち、い、に、う、に、か、いち、き、に、く」
になっちゃうから気を付けろ、っていうのがある。
実際、これを避けるためにWCAGでは
<ul>
<li>1. あ
<ul><li>1.1 い</li><li>1.2 う</li></ul>
</li>
<li>2. か
<ul><li>2.1 き</li><li>2.2 く</li></ul>
</li>
</ul>
こういう目次を書いている。どう考えてもそりゃ読み上げブラウザの実装がへぼいから
問題になるんだけど、こういう事例を考えると引用符はつけないにしても
少なくともcite要素とa要素を組み合わせたソースコードは
書き入れたほうがいいんではないかと。ターゲットにWinIEがあるんならね。
WCAGの中にolに関する記述があって、曰く
読み上げブラウザで読ませると単なるolの入れ子関係が掴めなくなる。
っていうんだけど、例を挙げると
<ol>
<li>あ
<ol><li>い</li><li>う</li></ol>
</li>
<li>か
<ol><li>き</li><li>く</li></ol>
</li>
</ol>
これを読ませると
「いち、あ、いち、い、に、う、に、か、いち、き、に、く」
になっちゃうから気を付けろ、っていうのがある。
実際、これを避けるためにWCAGでは
<ul>
<li>1. あ
<ul><li>1.1 い</li><li>1.2 う</li></ul>
</li>
<li>2. か
<ul><li>2.1 き</li><li>2.2 く</li></ul>
</li>
</ul>
こういう目次を書いている。どう考えてもそりゃ読み上げブラウザの実装がへぼいから
問題になるんだけど、こういう事例を考えると引用符はつけないにしても
少なくともcite要素とa要素を組み合わせたソースコードは
書き入れたほうがいいんではないかと。ターゲットにWinIEがあるんならね。
152 ：84：01/10/15 16:59 ID:NPXDzqIJ
>>148
それは当然区別するだろう。
だから「」で括られた部分は無視せずに適切にマークアップしたら? となるのだけど。
自らの創作物を全て引用だと言うのはあまりにも不可思議。
文字化された表現は全て引用とでも言うのか。
重要なのは書き手の意図。
引用表現として「」を使った場合には q 要素になるし、
強調表現として「」を使った場合には em 要素や blockquote 要素になる。
というのはこのスレでは既に述べられていることなんだけど。
書き手が常に「」を引用目的で使わないのであれば、
その定義は曖昧にならないか?
誰か (含む自分) からの引用だと思うのであれば
q 要素として適切にマークアップしたらいい。
とても引用だとは思えないのであれば
q 要素としてマークアップせずに他の要素で適切にマークアップしたらいい。
あともう一つ付け加えるなら、「」で書かれた部分は
常に著作権法上の引用に当たるかどうか、という見方もできる。
「」で括られる度にどこからの引用なのか明記するのか。
自らの著作物の先頭で「特に明記されていない限り、引用部分は
著者の脳内からの引用です」などと書くのか。
そこまで行くと電波だろう。
ところで、145 は「だったらどうマークアップすべきか」という
事について語ってくれないか?
創作物はすべからく引用だとか、そういう事を語りたいのであれば
別の板でやってくれ。
ここはインライン引用についてどーよ? という為のスレだ。
それは当然区別するだろう。
だから「」で括られた部分は無視せずに適切にマークアップしたら? となるのだけど。
自らの創作物を全て引用だと言うのはあまりにも不可思議。
文字化された表現は全て引用とでも言うのか。
重要なのは書き手の意図。
引用表現として「」を使った場合には q 要素になるし、
強調表現として「」を使った場合には em 要素や blockquote 要素になる。
というのはこのスレでは既に述べられていることなんだけど。
書き手が常に「」を引用目的で使わないのであれば、
その定義は曖昧にならないか?
誰か (含む自分) からの引用だと思うのであれば
q 要素として適切にマークアップしたらいい。
とても引用だとは思えないのであれば
q 要素としてマークアップせずに他の要素で適切にマークアップしたらいい。
あともう一つ付け加えるなら、「」で書かれた部分は
常に著作権法上の引用に当たるかどうか、という見方もできる。
「」で括られる度にどこからの引用なのか明記するのか。
自らの著作物の先頭で「特に明記されていない限り、引用部分は
著者の脳内からの引用です」などと書くのか。
そこまで行くと電波だろう。
ところで、145 は「だったらどうマークアップすべきか」という
事について語ってくれないか?
創作物はすべからく引用だとか、そういう事を語りたいのであれば
別の板でやってくれ。
ここはインライン引用についてどーよ? という為のスレだ。
>引用表現として「」を使った場合には q 要素になるし、
>強調表現として「」を使った場合には em 要素や blockquote 要素になる。
>>引用表現として「」を使った場合には q 要素や blockquote 要素になるし、
>>強調表現として「」を使った場合には em 要素や strong 要素になる。
>強調表現として「」を使った場合には em 要素や blockquote 要素になる。
>>引用表現として「」を使った場合には q 要素や blockquote 要素になるし、
>>強調表現として「」を使った場合には em 要素や strong 要素になる。
154 ：Name_Not_Found：01/10/15 17:55 ID:fJrSDeyC
>>151
自分だったら、olにtitle付けるかも。
自分だったら、olにtitle付けるかも。
155 ：Name_Not_Found：01/10/15 18:00 ID:SM8VuyU6
>146
WinIEにもそういうやつないの？
引用符付けて、引用元表示。
MacIE5べんりセットと仕組みは大差ないと思うのだけど。
# MacIE5は引用符元々付くから、
# 最低限の対応のうち一つはクリアしてるんじゃないか？。
WinIEにもそういうやつないの？
引用符付けて、引用元表示。
MacIE5べんりセットと仕組みは大差ないと思うのだけど。
# MacIE5は引用符元々付くから、
# 最低限の対応のうち一つはクリアしてるんじゃないか？。
156 ：Name_Not_Found：01/10/15 18:10 ID:SM8VuyU6
>>152
<q>すべからく引用</q>だって。あいたた。
<q>すべからく引用</q>だって。あいたた。
157 ：84：01/10/15 22:29 ID:22b/bVk8
>>152
＞ここはインライン引用についてどーよ? という為のスレだ。
はい、もちろんその通りです。
ただその前提として、「」は邦文における引用符であるってことを認めてくれればいいんで。
強調や台詞に使用する鉤括弧もその本質たる引用符としての機能の延長である、と。
しかし確かにこの議論は横道ですから、お呼びでなければもう書き込みますまい。
HTMLでどうするかのお訊ねですが、私のサイトの場合、引用はblockquoteが多く、
q要素はほとんど使用しません。するとしてもＣＳＳで引用符の内容生成は避けさせます。
＞ここはインライン引用についてどーよ? という為のスレだ。
はい、もちろんその通りです。
ただその前提として、「」は邦文における引用符であるってことを認めてくれればいいんで。
強調や台詞に使用する鉤括弧もその本質たる引用符としての機能の延長である、と。
しかし確かにこの議論は横道ですから、お呼びでなければもう書き込みますまい。
HTMLでどうするかのお訊ねですが、私のサイトの場合、引用はblockquoteが多く、
q要素はほとんど使用しません。するとしてもＣＳＳで引用符の内容生成は避けさせます。
>>154
加えて CSS で読み方に対して何らかの対策を行う、かな。
折角 aural media 向けのスタイルが用意されているのだから。
>>158
「」の引用符としての機能は認めているが?
ただ、「」がある場合に、常にそれを引用と認識することは無理。
自らの思想などを表現するために記述した言葉の中で、
より強調したい部分を「」で括ったら「それは脳内からの引用だ」は
あまりにも無理がありすぎ。
引用とは普通、既に明文化された著作物から行われるもの。
広辞苑第五版から引っ張ってくると
かっ‐こ【括弧】クワツ‥
数式や文章の中で、ある部分をかこって、他との区別を明らかにするための記号。()「」『』[]〔〕〈〉｛}など種々の形がある。「―でくくる」
かぎ‐かっこ【鉤括弧】‥クワツ‥
文章表記・印刷に用いる記号の一。「」『』など。
だな。
特に引用だと明示する言葉はない。
加えて CSS で読み方に対して何らかの対策を行う、かな。
折角 aural media 向けのスタイルが用意されているのだから。
>>158
「」の引用符としての機能は認めているが?
ただ、「」がある場合に、常にそれを引用と認識することは無理。
自らの思想などを表現するために記述した言葉の中で、
より強調したい部分を「」で括ったら「それは脳内からの引用だ」は
あまりにも無理がありすぎ。
引用とは普通、既に明文化された著作物から行われるもの。
広辞苑第五版から引っ張ってくると
かっ‐こ【括弧】クワツ‥
数式や文章の中で、ある部分をかこって、他との区別を明らかにするための記号。()「」『』[]〔〕〈〉｛}など種々の形がある。「―でくくる」
かぎ‐かっこ【鉤括弧】‥クワツ‥
文章表記・印刷に用いる記号の一。「」『』など。
だな。
特に引用だと明示する言葉はない。
160 ：Name_Not_Found：01/10/16 08:40 ID:My1U3jo8
161 ：Name_Not_Found：01/10/16 14:00 ID:c3Efb2ew
>>155
うん、引用符付けたり引用元を表示したりするJavaScriptを使えば
少なくともJavaScript:onのIE5以降へのアクセシビリティは確保できるんじゃないのかなーって思うんだ。
実際、問題になるのはIEが対応してないからでしょ？
うん、引用符付けたり引用元を表示したりするJavaScriptを使えば
少なくともJavaScript:onのIE5以降へのアクセシビリティは確保できるんじゃないのかなーって思うんだ。
実際、問題になるのはIEが対応してないからでしょ？
162 ：Name_Not_Found：01/10/16 16:05 ID:Ik5/d25/
>実際、問題になるのはIEが対応してないからでしょ？
IE次期Ver.が対応しても、この仕様は問題。
だって、昔ながらのブラウザ(IE3,NN4)を使ってる人はどうなるよ。
全てのPCユーザが最新のブラウザを使える環境にあるとは限らない。
IE次期Ver.が対応しても、この仕様は問題。
だって、昔ながらのブラウザ(IE3,NN4)を使ってる人はどうなるよ。
全てのPCユーザが最新のブラウザを使える環境にあるとは限らない。
163 ：Name_Not_Found：01/10/16 22:39 ID:DneP4EM0
>>162
IE3やNN4はそれ以前の問題と思われ。
Qの他にもっと一杯不具合があるだろうに。
ユーザが不具合を知らないことが一番の問題か。
特にNN4.xは意加減にしてくれ。
へぼデザイナーが布教活動してるからいかんのだ。
IE3やNN4はそれ以前の問題と思われ。
Qの他にもっと一杯不具合があるだろうに。
ユーザが不具合を知らないことが一番の問題か。
特にNN4.xは意加減にしてくれ。
へぼデザイナーが布教活動してるからいかんのだ。
164 ：Name_Not_Found：01/10/17 02:04 ID:qiFIlFdl
このスレ読んでると、
HTMLは小説の記述にゃ向かねぇなぁ〜
というのが感想
HTMLは小説の記述にゃ向かねぇなぁ〜
というのが感想
165 ：Name_Not_Found：01/10/17 16:02 ID:gfwgIwuZ
>>164
もともとが英文、しかも学者が使うものだったからな。
自前で小説用XMLアプリを作ってXSLTで整形させるのが一番かと。
そう言えば昔小説用のSGMLアプリがあったって聞いたことがあるけど、
どんなんだったんだろ？
もともとが英文、しかも学者が使うものだったからな。
自前で小説用XMLアプリを作ってXSLTで整形させるのが一番かと。
そう言えば昔小説用のSGMLアプリがあったって聞いたことがあるけど、
どんなんだったんだろ？
166 ：Name_Not_Found：01/10/18 01:14 ID:TB8ul8gR
>>164
会話文はqで括って、前後に改行が入る/入らないでクラス分け。
それほど向かないとも思わないが。
なんでqに引用符が付く仕様なのか、ちょっと調べてみたら、
SGMLの初期からqには引用符を付けることになっていたらしい。
これは元々SGMLが、論理構造をマークアップして、
それに印刷指定(スタイルシート的な)をかぶせるために使われていたという
歴史的な事情による物だと思う。
どんな引用符を付けるか、印刷ぎりぎりの段になってから
考えることができるように、ってことだ。
というか地の文に引用符を付けたら、
後で引用符を変更する、という作業ができないからな。
>>165
小説用のSGMLアプリくらい、割とかんたんに作れると思うが…。
でも、今はXML使った方が何かと便利だろうな。
会話文はqで括って、前後に改行が入る/入らないでクラス分け。
それほど向かないとも思わないが。
なんでqに引用符が付く仕様なのか、ちょっと調べてみたら、
SGMLの初期からqには引用符を付けることになっていたらしい。
これは元々SGMLが、論理構造をマークアップして、
それに印刷指定(スタイルシート的な)をかぶせるために使われていたという
歴史的な事情による物だと思う。
どんな引用符を付けるか、印刷ぎりぎりの段になってから
考えることができるように、ってことだ。
というか地の文に引用符を付けたら、
後で引用符を変更する、という作業ができないからな。
>>165
小説用のSGMLアプリくらい、割とかんたんに作れると思うが…。
でも、今はXML使った方が何かと便利だろうな。
167 ：Name_Not_Found：01/10/19 14:32 ID:59tAeegy
って事は、SGMLの世界じゃQに引用符を付けるのはUAってのが
デファクトスタンダードだったって事？
デファクトスタンダードだったって事？
168 ：168：01/10/19 16:14 ID:mA4MjRxn
私も知りたい、age。
寧ろ、引用符を付ける為のq要素だったと思われ。
それこそ、引用符の付く部分は意味に拘わらずq要素としていたはず。
内容がいわゆる引用かどうかはあまり関係なかったものと思われる。
「<q>文章</q>」とやってしまったら引用符の変更はできなくなっちゃうから、
<q>文章</q>として、引用符は後で変更できるようにしていた。
SGMLでは「あとで印刷指定をすること」を前提にしたマークアップが主流だった。
HTMLでは、もっと汎用な使えることが分かってきたから、
あくまで論理構造を示すことを主眼としてのマークアップに変わった。
だから、q要素の定義の仕方も、物理要素的に発生したものを
やや恣意的に論理要素と見做したような感がある。
その辺りに無理があったかな。
もっと古いバージョンからq要素を定義していれば良かったろうに。
# ただ、このことを考えてもやっぱりWinIEの対応はおかしいとしか思えないな。
# 何か凄く分かりづらい文章になってしまってｽﾏｿ。
それこそ、引用符の付く部分は意味に拘わらずq要素としていたはず。
内容がいわゆる引用かどうかはあまり関係なかったものと思われる。
「<q>文章</q>」とやってしまったら引用符の変更はできなくなっちゃうから、
<q>文章</q>として、引用符は後で変更できるようにしていた。
SGMLでは「あとで印刷指定をすること」を前提にしたマークアップが主流だった。
HTMLでは、もっと汎用な使えることが分かってきたから、
あくまで論理構造を示すことを主眼としてのマークアップに変わった。
だから、q要素の定義の仕方も、物理要素的に発生したものを
やや恣意的に論理要素と見做したような感がある。
その辺りに無理があったかな。
もっと古いバージョンからq要素を定義していれば良かったろうに。
# ただ、このことを考えてもやっぱりWinIEの対応はおかしいとしか思えないな。
# 何か凄く分かりづらい文章になってしまってｽﾏｿ。
170 ：Name_Not_Found：
そもそも。
リストマーク位ならまだしもでしたが、
引用符とかそのほか内容生成をさせるタグやプロパティはあまり設定すべきでない、
と愚考しますね。
CSSオフや古いブラウザでも読むのに支障がないHTMLが基本なわけだし。
リストマーク位ならまだしもでしたが、
引用符とかそのほか内容生成をさせるタグやプロパティはあまり設定すべきでない、
と愚考しますね。
CSSオフや古いブラウザでも読むのに支障がないHTMLが基本なわけだし。