[prev] [sitemap] [gateway] [next]

Another HTML-lint FAQ

目次　
はじめに　　　　　　 　ゲートウェイサーヴィス
いくつかの覚え書き　 　　　　簡易ゲートウェイ
htmllint.cgiの使い方 　　　　　　　結果の解説
htmllintの使い方　　 　　　　　　　　タグ一覧
規則ファイルの生成　 　　　　　　　　　色見本
ダウンロード　　　　
メーリングリスト　　
参考までに　　　　　 　　作者にビールをおごる
よくある質問と答　　 　　　　プライマリサイト

よくある質問と答

こんな質問、ほんとによくあるのか? というのは置いといてください。

Q
総本山W3Cのサーヴィス「W3C HTML Validation Service」とどう違うのですか。
A
W3Cのサーヴィスは、HTMLをDTD的に検証するだけです。しかし、W3Cの策定しているHTMLの仕様書中や、DTDのコメント中には、DTDでは表現できない多種多様な制約事項が述べられています。W3Cの検証ではそのようなチェックは一切行なわれません。例えばHTML4などで、<OL type> の値は、DTDではCDATAとしか書かれていませんが、実際は "(1|a|A|i|I)" であるべきことがコメント中に明記されています。DTDではそのような表現ができないからです。W3Cの検証はそのようなチェックはしません(できません)。つまり、<OL type="USO800"> と書いてもエラーにはなりません。Another HTML-lint はそのようなことも含めて、仕様書中の瑣末なことまで、なるべくチェックするよう努力しています。
というわけで、はっきり言って、W3Cの検証でお墨付きをもらったとしても、DTD的に正当なだけで、HTML的に正当かどうかの保証は一切ありません。しかし、Another HTML-lint のDTD的検証にはだいぶ手抜きがあります。W3Cの検証も是非行なってください。
Q
満点ならどんなブラウザでもちゃんと見れるのですか。
A
そんな保証はありません。指定された文法的なチェックをするだけで、見え方まではわかりません。特定の環境でちゃんと見えるようにするためには、減点が不可避なこともあります。
また、WAIで言われているアクセス性に関するチェックは、ごく一部しかできません。この勧告文書(加藤泰孝氏が訳されています)をちゃんと読んで、よりよいHTMLを書いてください。
満点である必要はありません。…と言うと、無理解のまま「満点の必要はありません」と宣伝する方々がいらっしゃいます。発言には十分気を付けましょう。
Q
結果の評価は信用できるのですか。
A
人の言うことは、眉唾だと思うことが基本です。相手がどんな権威でも、盲信するのは危険です。信用に足るかどうかは自分で判断するしかありません。そういう判断ができる知識を身に付けましょう。評論家になるのはその後です。
Q
ちゃんと見えるのだから、文法なんか守らなくてもいいじゃないか。
A
あなたの環境でちゃんと見えているのであって、隣の人もちゃんと見えるかどうかはわかりません。大勢の人々に見てもらおうというのなら、誰もがちゃんと見えるようにしなければならないのですが、それには決められた文法を守って書くことが必要です(十分ではありません)。
しかし、現実には文法を守らなくても、優秀なWWWブラウザが適当に不備を補ってくれるので、かなりいいかげんに書いても多くの人々にはちゃんと見えます。だから、今のところ文法に関してルーズでも困ることはあまりありません。でも、文法的に正しければより多くの人にちゃんと見てもらえます。HTMLの未来がXMLにあるのなら、文法違反はご法度になる方向にあるということです。
チェックで満点を目指すというのは、「正しい日本語を話しましょう」というのと似ていなくもないですが、HTML文法は自然言語じゃないのでちと違います。ちょいとばかし堅苦しいところがある点は同じです。満点だからといって、それでは十分でないことに気付いてください。Another HTML-lint がチェックするのは文書の内容ではないのです。正しい日本語でたわけたことを言っていてもしょうがありません。文法よりも、内容が大事なことは明々白々ですが、文法を正したからといって、内容が損なわれることはありません。
Q
大手有名サイトでもひどい点数です。文法なんか守る必要ないと思います。
A
その超有名サイトの技術者が、W3Cの仕様を守る技術力を持っていないというだけのことでしょう。もし、思惑通りに表示させるためにあえて違反を犯しているのなら、HTMLを採用すべきではありません。どうしてもHTMLを使いたいなら、W3Cに仕様変更を求めるべきです。あるいは、HTMLより優れたプロトコルを設計し、広く世間に流布させればいいのです。
Q
エラーの解説が難し過ぎてちんぷんかんぷんです。
A
なるべく平易に書くように努めているつもりなのですが(どこがじゃ)、どうもHTMLの基礎的なことは端折ってしまいがちです。部分部分で「ここがわからない」という指摘はその都度書き換えなどをしたいと思いますが、総体的にわからないというのであれば、他の優れた方々のサイトを巡ってHTMLの基礎を勉強してください。
Q
参考書に書かれているとおりにHTMLを書いているのにエラーが沢山出ます。
A
はっきり言って、その参考書が間違っています。あやしい本やのけぞる本！が詳しいです。
Q
HTMLを作成するツールを使ってHTMLを書いているのにエラーが沢山出ます。
A
残念なことに、正しいHTML文法の認知度が非常に低いからです。このような間違ったHTMLを生成するオーサリングツールの開発者達は、MozillaやMSIEなどの目的とするWWWブラウザでちゃんと見えればよいようにHTMLタグを生成しようとしているのです。そのようなオーサリングツールは、最初のラフなHTML生成用に使用し、その後テキストエディタで手直しする必要があるかも知れません。
これはとてもおかしな話で、これでは何のためのオーサリングツールかわかりませんね。
Q
私の利用しているプロバイダでは、ページの頭などに広告が挿入されてしまい、それが減点を招きます。その部分をチェックから外せませんか。
A
残念ながらできません。チェックするときに得られるHTMLからは、それが広告主によって挿入されたものか、ページ製作者の意図したものかの区別が文法的にできないからです。
しかし、広告を除いてチェックして高得点を得ても、あなたが広告付きプロバイダを利用する限り意味がありません。あなたのサイトを訪れる人は広告付きのHTMLを表示しようとするからです。広告部分に致命的な欠陥があるのなら、あなたのサイトは閲覧できない可能性が高いことに変わりはありません。あなたのサイトの評価は広告込みで行なわれるべきです。そこに広告が表示されるのは、そのプロバイダを選んだあなたの責任であり、広告はあなたのHTMLの一部です。 プロバイダ提供のCGI等でも同様です。
Q
とてもエラーが多くて直す気にもなりません。
A
基本的なタグ付けの方法が正しくないと思われますので、HTMLの基礎を勉強し直しましょう。
また、DOCTYPE宣言がないときは、とりあえず、文書の先頭に 
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
と書いておいてください。そして、この行の意味を勉強してください。
もし、すでにDOCTYPE宣言があるのにエラーが多い場合は、HTMLヴァージョンにいろいろあることをあまり理解できていないために、不適切なDOCTYPE宣言であることが考えられますが、深く理解するのなんかさらさらごめん、という方は、やはり上のDOCTYPEに改めてみてください。Transitionalがあるとないでは大違いなので注意しましょう。
宗教的なチェックなどを無効にしても、エラーがずいぶん減ります。
Q
でもやっぱりエラーが多くて直す気になりません。
A
過去のしがらみを捨て、最初から書き直しましょう。
Q
満点を取るにはどうすればいいのですか。
A
満点を取ることを目標にしてはいけません。例えば以下のような修正は、あなたのHTMLを満点に導きます。 でも、これらは表現方法を変えてはいるものの、相変わらず物理的な記述をしており、とてもよいHTMLとは言えません。文章に論理的な意味を与えていません。なぜ文字を赤くしたいのか、なぜ中央寄せしたいのかを考えましょう。<br /> の例などはとてもひどいもので、涙が出ちゃうくらいです。targetによる方向付けは、そういう行為自体を戒めているものなのに、targetじゃなければいいなどという発想自体がおかしいのです。
Q
DOCTYPEって何ですか。
A
書かれているHTML文書が、どういったHTMLかを示すためのものです。これは、例えば、「この文書は津軽弁で記述されています」といったようなことに相当します。HTMLにいろいろなものがあるのは、HTML4.0だとかHTML3.2だとかいうのがあるので、薄々気付いているでしょう。だから、HTML3.2の参考書を見て書いたHTMLの先頭には、「HTML3.2で書かれた文書です」と宣言するわけです。結果の解説などを読んでください。
Q
MSIE用にHTMLを書いていますが、DOCTYPEがないと言われます。どうすればいいのですか。
A
MozillaやMSIEにはHTMLの正式な文法がありません。この文法は Document Type Definition (DTD/文書型定義) と呼ばれるものです。DOCTYPEは、HTML文書がどのDTDに則って書かれているかを示すものなので、DTDの存在しないMozillaやMSIE用のHTML文書にDOCTYPE宣言をすることはできません。HTMLをMozillaやMSIE用としてチェックさせるには、HTMLヴァージョンをそれぞれ該当するものに変更してからチェックしてください。
Q
納得できないエラーがあります。
A
ほとんどすべてのエラーは、わたしの主観によるものではありません。エラーにはすべて出典があります。文句はその出典元(W3CとかIETFとか)へ言ってください。宗教的や経験的とされているものでもそうなのですが、出典元がうさんくさいものや、多少主観の入っているものもあります。納得できない理由を客観的に分析してみましょう。 まあ、わたしの理解が足りない場合や、プログラムミスによって間違った判定をされることも大いにあり得ますので、「変だ」と思ったら k16@chiba.email.ne.jp までメールでもしてください。
Q
文字コードが誤判定されます。
A
まれに、日本語の文字コードを誤判定することがあります。これは、日本語の文字コードがごくわずかしか含まれないときや、短い日本語文字コードが最初に現れてから、次が現れるまでだいぶ間が空いているようなときです。HTML文書の最初の方に、コメントとして適当な日本語を入れておくことで回避できます。
Q
Mozillaで見ると、Mozillaがクラッシュしてしまうページがあるのですが。
A
Mozillaのヴァージョンによって、いくつかの書籍のあらさがしなどの一部のページを見ようとすると、クラッシュしてしまうことがあるようです。Mozillaがスタイルシートの処理をうまく行なえないのが原因なのですが、どのような記述が直接の引き金になっているのか特定できていません。クラッシュするページでJavaScriptは使用していませんが、当該ページを見る前に一度でもJavaScriptが動作しているとだめなようです。JavaScriptを無効にするなどしてください。申し訳ありません(わたしが謝る筋合いのものではないんだけど)。
蛇足ですが、Mozilla4.5(やそれ以前)のスタイルシートの対応度は評価以前のレベルです。MSIE3のスタイルシートは使わないでください。MSIE4.5やMSIE5だとそこそこです。
Q
MacのMozillaで見ると、htmllint.htmlが正しく表示されません。
A
たぶんMacのMozilla(4.5)などのJavaScript処理で、JISコードの扱いがうまくないのが原因のようです。再読み込みさせればちゃんと見えると思います。
Q
チェックしようとすると、cgi-lib.pl: Unknown Content-type: application/x-www-form-urlencoded; charset=iso-2022-jp と出てチェックできません。
A
一部のユーザエージェント(Lynx2.8jなど)が、フォームの送出に際してこのようなContent-typeを送出するようで、cgi-lib.plを利用しているとこのような症状が出るようです。cgi-lib.plをパッチするか、Content-typeに charset=iso-2022-jp を付けないようにLynxを改造してください。
CGI.pmではこのようなことはないようです。
Q
Another HTML-lint をインストールしましたが、結果のHTMLなどが文字化けします。
A
すべて正しい設定であるとして、Perl の作られ方によっては jcode.pl がうまく動作しないことがあります(どのヴァージョンの Perl が該当するのかはちゃんと調べてません)。例えば、次のようなテストスクリプトを走らせてみてください。 
    $x = 'abcd';
    &foo(*x);
    sub foo {
      local(*_) = @_;
      print $_;
    }
正しく abcd と表示されない場合は、-Dusethread して作られた Perl の可能性があります。それを外して作り直してみてください。また、どうしてもスレッド処理したいときは、jcode.pl に手を入れれば動くようになります。local(*_) などが my(*_) として評価されてしまうのが原因です。local(*v) のように名前を付ければ問題なくなります (local($_) などもだよ)。jcode.pl のそのような部分すべてに名前を付ければ動作します。しかし、他の Perl スクリプトにやはり動かないものが出てくるので、これでは根本的な解決にはなりません。(jcode.pl 2.11 ではこの問題は改修されているそうです。)
なお、現在は、jcode.plではなく、Jcode.pmを使用しています。このときは、このような問題は発生しないと思われます。
Q
サーバに w3m をインストールしましたが Another HTML-lint で結果が表示されません。
A
デフォルトで、-Mオプションを付けてw3mを呼び出すため、カラー機能を無効にしてコンパイルされたw3mでうまく動作しないようです。カラー機能を有効にするか、htmllint.env で 
    $W3M = '/usr/local/bin/w3m -dump -T text/html -e';
などと -M のないオプションを指定してください(オプションの詳細はw3mを参照のこと)。
Q
Another HTML-lint にはセキュリティの問題はありませんか。
A
Another HTML-lint は、CGIとして次のように動作します。
  1. 指定されたURLに対応するリソースを取得し、それをワークファイルに保存します。ファイルサイズには上限を設けています。
  2. データ領域に直接指定されている場合や、クライアント上のファイル名が指定されている場合は、それをワークファイルに保存します。
  3. URLから取得したものがHTMLでなかった(text/htmlでなかった)場合は、それを消去してエラーとして処理を終えます。
  4. 取得したファイルを htmllint.pm でチェックします。
  5. HTML中のリンク先が実存チェックの指定があるときは、そのURLのヘッダ情報を求めます。URLの内容取得は行ないません。
  6. ワークファイルを消去します。
  7. 結果を返します。
秘密のURLを指定してチェックを行なえば、サーバはそれを知り得ます。ログにも残ります。具合の悪いときは、ローカルなサーバを用意するなどしてください。
また、ゲートウェイである htmllint.html/htmllinte.html は、JavaScriptを利用してクッキーを操作します。この情報はクライアント側でのみ利用するもので、チェックの状態などの保持を行ないます。クッキーを使ってのサーバとのやり取りはありません。
Q
HDML(Handheld Device Markup Language)には対応しないのですか。
A
プロトコルが全然違うので、ちょっと難しいです。 データ領域指定などだけならできるかもなぁ。
Q
Another HTML-lint はどうして JPerl で動かないのですか。
A
わたしが JPerl で動かそうと努力していないからです。たぶん今後もしません。運がよければ動くかも知れませんが、保証の限りではありません。 JPerl でうまくいかない最大の要因は、Shift JIS コードでの正規表現中の日本語の扱いによるものです。Another HTML-lint でも、ごく一部にそのような正規表現を使用していますが、Perl スクリプトが Shift JIS のときは、うまく動くようにエスケープ処理を行なっています。
Q
Another HTML-lint を Ruby で動かすにはどうすればいいのですか。
A
移植してください。あなたの腕次第です。なお、当然ですが、この Ruby と、W3Cにある Ruby はまったく別物(紛らわしいなぁ)。
Q
こんなすばらしいソフトを無償で提供していただいて、感謝の意を表わしたいのですが。
A
来るものは拒みません。貧乏な開発者のためにビールでも何でもおごってください。ご遠慮なさらずにいつでもどうぞ。次のようなおごり方があります。
Q
Another HTML-lint を営利目的に利用したいのですが。
A
金儲けの道具として Another HTML-lint を使うときは、何がしかのお布施をいただけると助かります。例えば、プロのWeb屋さんが開発ツールとして利用する、ミラーもどきサイトを構築して広告収入を得る、おまけ以外の目的で書籍に添付する、授業(特に私立の)で生徒のHTMLの質の判断基準に利用する、などです。最後のは、国立大民営化なんてハナシがあって私立との差別もなんだかなぁ、と思い始めている。
Q
スポンサーになりたいのですが。
A
非常に居心地のよい RingServer では広告は禁止されているので、スポンサー様の広告を挿入するためには別のサーバへ引っ越す必要があります。いたれりつくせりサーバを用意してくださるのなら、引越しを考えますが。

このサイトの運営は作者が行なっているわけではありませんのでご注意ください。
作者が管理しているのはプライマリサイトだけです。
このサイトの管理人はその連絡先を明記してください。明記されていないサイトは正しくない利用形態です。

Updated: Jul 07, 2005
Created: Jun 06, 1999 © by k16@chiba.email.ne.jp
[prev] [sitemap] [gateway] [next]