新生鳩丸掲示板♯

>アクセス性を(仕様よりも)重視しているという趣旨の発言がなされたものと理解したのですが、ではなぜこのサイトのリソースはUTF-8で記述されているのだろうかとか、そのへんが疑問になったもので。

　なるほど了解しました。

　実は携帯電話に限らず、ちょっと古めの w3m だと読めないとかいった問題もあります。というわけで、いちおう問題点としては認識しています。

　では何故解消されていないのかというと、これは単純に私の力不足によるものです。

　まず鳩丸のほうですが、こちらは当初 ISO-2022-JP のみだったのを、Accept-Charset によるコンテント･ネゴシエーションによって Shift_JIS やら UTF-8 やらを提供する形にしたという経緯があります。

　こちらも本来ならばそうするべきなのですが、まず IIS では Accept-Charset によるコンテント･ネゴシエーションができません (いやひょっとしたらできるのかもしれませんが、やり方がわかりません)。

　そんなわけで、コンテント･ネゴシエーションを実装するには何らかの動的生成方法を採用する必要があります。それはいちおう採用しているので、実装しようと思えば可能は可能なのだろうと思いますが、具体的にどのように実装するのかが見えていない状態です。

　hatomaru.dll にはまだまだ未完成の部分がありますので、徐々に強化していきたいと思っています。

>　ええと、質問の主旨が良く分からないのですが……。

アクセス性を(仕様よりも)重視しているという趣旨の発言がなされたものと理解したのですが、ではなぜこのサイトのリソースはUTF-8で記述されているのだろうかとか、そのへんが疑問になったもので。

webを閲覧できる携帯電話やPHSがあることはご存知だと思います。そしてそのユーザー数は、おそらくPCでwebを見ている者より多いだろうことも。もちろん併用している人も多数いると思いますが、PCを持たずに携帯だけでwebをアクセスしている人も多数います。（つーか私のまわりはほとんどそうです。）

>>私はいつもアクセス性を重視しているのであって、

>携帯電話のWeb閲覧機能に対するアクセス性については、どのように考えていますか？

まずこの質問には、"携帯電話のWeb閲覧機能に対するアクセス性について"「重視する」という回答か「無視もしくは軽視する」という

回答を想定していました。

で、もし「重視する」という回答なら、じゃあなぜUTF-8なのですかとか質問するつもりでいました。

「無視もしくは軽視する」という回答なら、次には当然、「それは何故ですか？」という質問がでてきます。（まあ内容がPCユーザしか関心をもたないような内容だからというなら一応納得しますが）

>div（およびspan）には、次の２つの効果があるということですよね。

>１．id属性及び class属性と併用して、文書に構造を付加する

>２．スタイルシートやlang属性等と併用して、HTMLの見栄えを整える

>「併用する」というのは義務ですか？

　DTD 的には併用する必要は特にありませんが、そもそも特定の意味を持たない要素ですので、属性が何もない div や span にはあまり意味がないように思います。

　もっとも、文脈セレクタでスタイルを定義したりもできますので、全く意味がないわけでもありませんが……。

>「divをなくしても valid なマーク付けをすべきだ」という考え方は有りだと思いますが、そのあたりはもう好みの問題

>「俺ルール」、理由を訊かれても「（俺には）その方がわかりやすい」とか「なんとなく」としか答えられません。

わかりました。

いちおう、もう一度つっこんで伺っておきます。

英語難しいので邦訳版から引用http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.4

>DIV要素とSPAN要素は、id属性及び class属性と併用する

>ことで、文書に構造を付加するための一般機構を提供する。

>各々、内容が行内であるか(SPAN)ブロックレベルであるか(DIV)は

>定めるが、他のプレゼンテーション的語彙を示すことはない。

>従って著者は、この両要素をスタイルシートやlang属性等と

>併用することで、HTMLを自身の必要や好みに応じられるように

>できる。

div（およびspan）には、次の２つの効果があるということですよね。

１．id属性及び class属性と併用して、文書に構造を付加する

２．スタイルシートやlang属性等と併用して、HTMLの見栄えを整える

「併用する」というのは義務ですか？

>携帯電話のWeb閲覧機能に対するアクセス性については、どのように考えていますか？

　ええと、質問の主旨が良く分からないのですが……。

その要素が段落である場合はp、見出しである場合はh1～h6、順不同のリストであるならul……と考えていって、既存のブロック要素のどれにも当てはまらないような場合はdivでマーク付けしてしまってよいのでは。

個人的には、そういう「既存のどの要素にも当てはまらないブロック」はpでマーク付けしており、「divの中身はブロックだけにする（divをなくしてもvalidなマーク付け）」という「俺ルール」を自分に課していたりするのですが、理由を訊かれても「（俺には）その方がわかりやすい」とか「なんとなく」としか答えられません。

>私はいつもアクセス性を重視しているのであって、

携帯電話のWeb閲覧機能に対するアクセス性については、どのように考えていますか？

>pやtableなどならインライン要素を入れていいのは分かるんですが、

>body直下のdivタグの中には、ブロック要素しか入れてはいけない？

>のではないかという疑問です。

>DTDというよりも、divの本来の意味からして、この考え方は間違っていますでしょうか？

　DTD 的には OK というところは理解されているものとお見受けしました。

　そうなると次は仕様書がどう言っているのかという話になってきますが、

http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.5.4

　あたりを見ても今ひとつ分かりません。いちおう div 直下に p要素と #PCDATA が混在している例が出ていて、そこには DEPRECATED EXAMPLE などと書かれてはいないようなので、仕様的には問題ないのではないと思います。

　あとはポリシーの問題で、「divをなくしても valid なマーク付けをすべきだ」という考え方は有りだと思いますが、そのあたりはもう好みの問題のような気がしています。

>HKEY_CLASSES_ROOT\MIME\Database\Content Type に application/xhtml+xml キーを作成。そこに文字列で Extension エントリを作成し値に .htm を指定することでHTMLとして表示できるようになります。

># IE6.0 で確認。

　わたしも確認済みです。というか、最初この設定をしていたことを忘れていて「あれ? 問題ないじゃん」と思ってしまったという……。

>　そもそも何で仕様が text/html で返すべきでない(SHOULD NOT)と言っているのかというと、旧来の UA が正しく解釈できない(=アクセス性が低下する)可能性があるからです。

　御意。

　いずれにしても現状は試験運用中ということで、正しく解釈できなくて問題が出る環境があるようでしたらご指摘いただければと思います。

はじめましてです。

> IE でダウンロードになってしまうのは……まあ頑張れば読めないことはないのでしょうが、それはかなり面倒ですので、事実上読めないに等しいと思います。

HKEY_CLASSES_ROOT\MIME\Database\Content Type に application/xhtml+xml キーを作成。そこに文字列で Extension エントリを作成し値に .htm を指定することでHTMLとして表示できるようになります。

# IE6.0 で確認。

　そもそも何で仕様が text/html で返すべきでない(SHOULD NOT)と言っているのかというと、旧来の UA が正しく解釈できない(=アクセス性が低下する)可能性があるからです。たとえば旧来の UA が xml:lang 属性を解釈できる可能性はまずありません。だから XHTML 1.0 の Appendix C では lang 属性と両方指定しろといっているわけですが、XHTML 1.1 では lang 属性が廃止されているのでどうにもなりません。というか互換性に配慮するのをやめたから廃止したわけですが。

　むろん application/xhtml+xml にしたところで読めるようになるわけではありませんが、これは本質的に application/pdf がダウンロードになるのと同じで、プラグインによる対応の余地があります。中途半端に HTML と解釈されてしまったらそれすら不可能です。

　部分的に正しく解釈できなくてもテキストとして表示できたほうがいいという考えもありますが、最近ではセキュリティ的に望まれなくなりつつあります。たとえば XHTML では script 要素の中身の <!--～--> はコメントですが、スクリプトに対応した旧来の UA のほとんどは script 要素中の <!--～--> を解釈するでしょう。もし application/xhtml+xml を中途半端に解釈する UA が存在すると、サニタイザー【謎】はコメントなのに <!--～--> の中身をフィルタリングしなければならなくなったりする恐怖れがあります。

　もっとも MSIE の場合 XML をフル解釈できる能力はあるはずなので質的に異なる問題のような気もしますが。PNG にフル対応できるはずなのに img 要素を使うとダメで別途定める謎マークアップが必要だとか。

す、すみません。

CSSだけで出来ました…(汗)。

ごめんなさいでした。。

はじめまして。

よそのサイトの例で恐縮なんですが、疑問におつきあいください。

その内容（引用ではない）ですが、

「body要素の下にはブロック要素しかいれられない！」

ダメ例：<body><img src="某"></body> →imgはインライン要素だからダメ。

divブロックでくくって、

良い例：<body><div><img src="某"></div></body>

ならばＯＫ

との例示でした。

pやtableなどならインライン要素を入れていいのは分かるんですが、

body直下のdivタグの中には、ブロック要素しか入れてはいけない？

のではないかという疑問です。

DTDというよりも、divの本来の意味からして、この考え方は間違っていますでしょうか？

PS：以下をOperaで開いて、見た目バグるのでソース見て、

「なにこれ～」でした。

http://www.microsoft.com/japan/technet/treeview/default.asp?url=/japan/technet/security/bulletin/ms04-004.asp

>　……あるいは、Accept: なり User-Agent なりを見て出力を変えるようにしても良いのですけれども。

　とりあえず、Accept: に application/xhtml+xml が含まれている場合だけ application/xhtml+xml を返すようにしたつもりです。Firefox などでは application/xhtml+xml になるはず。

　ちなみに場当たり的実装なので qvalue とかは見ていませんし Vary: も出力していません。:-)

>　まったく御意なのですが、しょぼいブラウザが存在するのが問題です。具体的には MSIE なのですが、「スタイルが無効だけどテキストとして読める」とかいうレベルですらないので困ります。いやまあ頑張れば読めないことはないですが……。

　ってあれ? ひょっとして Windows XP の IE6SP1 だと問題ない?

　……などと思ったら、わたしがレジストリをいじって application/xhtml+xml を .html に関連付けていたいたせいでした。別の環境だとしっかりダウンロードになって残念な思いを……。

>　スタイルが無効だけどテキストとして読める」とかいうレベルですらないので困ります。

下手に無理やり読むとそれが原因でホゥルになることもあるので(MSIEだし)完全に対応しているのでなければ読めないほうが望ましいと思います。

>最近、YukariCar/0.82 (Macintosh; U; PPC; Mac OS X)なるUA名を目にしたのですけど、ばけらさんはご存知でしょうか。

　ゆかり車ですか……。

　ログを grep してみましたが、うちには来ていないようです。

　ちょっと残念。

>HTTPSでもWindows Updateのサイトにアクセスできるのですね。

>https://v4.windowsupdate.microsoft.com/ja/default.asp

>https://windowsupdate.microsoft.com/

>だとHTTPSじゃないほうに飛ばされちゃいますけど

　あ、そうなんですね。知りませんでした。

#後者だけ見て駄目なものだとばかり思っていました。

>XHTML1.1以上では、text/htmlを返すべきではない。

>ような気もするのですが、どうでしょう。

　御意。

　まったく御意なのですが、しょぼいブラウザが存在するのが問題です。具体的には MSIE なのですが、「スタイルが無効だけどテキストとして読める」とかいうレベルですらないので困ります。いやまあ頑張れば読めないことはないですが……。

　というわけで、現時点ではこの件については「仕様に忠実に実装することによってアクセス性が向上する」という結果が得られないように思うので、正しく解釈するブラウザには申し訳なく思いつつもこんな感じにしているのです。

　……あるいは、Accept: なり User-Agent なりを見て出力を変えるようにしても良いのですけれども。