このページはレーシック・美容整形類義語辞典が 2006年 12月 02日 00時57分30秒 にクロールしたキャッシュ情報です。

検索キーワード＝ レーシック 美容整形 脂肪吸引
優先キーワード＝ レーシック 美容整形 脂肪吸引

解説とは？

[ 121] Another HTML-lint : Explanation
[引用サイト]　 http://openlab.ring.gr.jp/k16/htmllint/explain.html

文法的にもHTMLとしても正しいが、WAIやテクニカルノートなどで守らなければならない (優先度1) とされているもの。 *4*
文法的にもHTMLとしても正しいが、WAIやテクニカルノートやRFCで推奨されていないもの。 *3*
あまりエラーが多いときは、チェックを打ち切るようにしています。打ち切られた行以降の文書には、もしかしたら重要なエラーが含まれているかも知れませんが、チェックされません。同じようなエラーばかり出ているときは、そのエラーをチェックしないようにしてみてから、もう一度チェックしてみるといいでしょう。
もしも、同じ行の同じエラーがずっと繰り返されている場合は、プログラムの不具合だと思われますので、是非 k16@chiba.email.ne.jp までお知らせください。
指定されているURIが実際に存在するのかチェックしますが、処理の迅速化のためにタイムアウトの時間はかなり短く設定されています(変更可)。それでも、サーバの反応が遅いリンクが多い場合は時間がかかるでしょう。http: スキームのみチェックしています。ただし、正しくないURIのときはチェックしません。
メッセージの後に数字が付いている場合、それは、HTTPリクエストの結果のコードです。このコードは大きく分けて次のように分類されています。
これらのうち、このチェックで返ってくる可能性のあるコードでエラーとなるのは 400番以降のときです。しかし、確実にリソースが存在しないかアクセスできないのは次の場合くらいです。
認証が必要なもの(401)などはそのリソースが存在することは明らかですし、サーバエラーのときは存在するのかしないのかは不明です。Another HTML-lint ではこのようなリソースの文法チェックをすることはできません。
LWPでなくhttpreq.plを使っているとき、1桁のコードが返ることがあります。それは、HTTPリクエスト以前にエラーが発生したときで、次のような意味です。
JavaScriptなどを利用して <BASE> を動的に変更していたりする場合は正しくチェックできません。
一部のISPでは、受け付けるHTTPリクエストを制限していることがあります。このとき、「GETリクエストでチェック」オプションを指定していない場合は、すべてのURLに対して存在しないなどとエラーになりますのでご注意ください。
HTMLには、いろいろな仕様(ヴァージョン)があります。DOCTYPE宣言は、文書がHTMLであり、さらにどの仕様のHTMLで書かれているのかを明示するものです。DOCTYPE宣言がなくても、たいていのWWWブラウザは(自分の都合のいいように)HTMLを表示してくれますし、まじめにDOCTYPEによってHTMLの評価を変えてくれるWWWブラウザが現存するのかどうか知りません。しかし、DOCTYPE宣言は書くようにしましょう。とはいえ、MSIEやMozillaなどには対応するDOCTYPEがないので、にっちもさっちもいきません。
DOCTYPE宣言の前に、何か制御文字が含まれています。これは、JISのエスケープコードなど、不可視かも知れません。バイナリダンプなどでの調査が必要かも知れません。
現在 Another HTML-lint がサポートしているDOCTYPEは以下のとおりです。文法はそれぞれのタグ一覧を表示します。言い訳ですが、規則ファイルから動的に生成しているため、あまり親切な一覧ではありません。なお、以下「DOCTYPEはありません」と書いてあるのは、公開識別子がないという意味です。
DOCTYPE宣言の意味については、文書タイプ宣言の意味などを見てください。特に、宣言末の "EN" というのは、宣言されているDTDが英語で書かれているという意味で、そのHTML文書がどうこういう意味ではありません。勝手に "JA" などに書き換えてはいけません。
また、HTML4.0がHTML3.2の上位互換などということはありません。ほとんどのHTMLにはこのような互換性はありません。
もしも、あなたが使用しているDOCTYPEがここになくて、そのDTDが存在している場合は、k16@chiba.email.ne.jp までお知らせくだされば、追加できるかも知れません。
DOCTYPEに宣言されているHTML2.0やHTML3.0などは、すでに破棄されてしまった仕様です。使わないようにしましょう。
DOCTYPEに宣言されているHTML4.0は、使うことが薦められていません。改訂版のHTML4.01を使いましょう。この警告は減点されません。
DOCTYPE宣言は、コメントやXML宣言を除く文書の先頭に書かなければなりません。つまり、<HTML> より前に書かなければなりません。
DOCTYPE宣言中に指定されているシステム識別子が正しくありません。公開識別子に対応するシステム識別子は決まっています。
<!SGML 〜> とか <!ELEMENT 〜> とかいう宣言は、DOCTYPEを除いてすべて無視します。実際に存在する宣言かどうかはチェックしないので、でたらめな <!USO800 〜> とかでも黙って無視されます。実際には次のような宣言が存在します。
マーク区間というのは、<![CDATA[ 〜 ]]> のようにしてSGML文書の一部分にいろいろな性格付けをしたりするものですが、多くのWWWブラウザはこの書式を理解できませんし、Another HTML-lint もきちんとは解釈できません。HTML4.01(J)にもあまり使わない方がいいと言及があります。
としなければならなくなりました。Another HTML-lint では、CDATAマーク区間のみ、HTML4以上に限って解釈しています。他のマーク区間は、入れ子の関係が許されたりいろいろ複雑なので、かなり大雑把にしか扱っていませんし、意味を斟酌してもいません。覚え書きを見てください。
また、構文上 <![ CDATA [ のように空白を含められるのですが、手抜き実装のため、複数行に渡っての記述は解釈できません。閉じる場合も同様です。
スクリプトやスタイルシートの記述中にこういう字面を含むようなものをHTML中に埋め込むことはできません。そのようなときは外部にスクリプトやスタイルシートを用意しなければなりません。
ただし、チェックはCDATAマーク区間のみHTML4以上に限って行なっています。実際にこのエラーが出ることはありません。
マーク区間が閉じられていません。閉じる場所に関しては Another HTML-lint は無頓着です。
<?xml で始まるXML宣言は、文書の先頭に書かなければなりません。つまり、DOCTYPE宣言よりも前に書かなければなりません。
一般のSGML処理命令を閉じるのは ">" ですが、XML宣言を閉じるのは "?>" でなければなりません。
XML宣言の書式はXML(J)で決められています。ここで、属性の順序なども固定的であることに注意してください。Another HTML-lint では、具体的な属性値に立ち入ってまではあまりチェックしていませんが、version="1.0" であることはチェックされます。
Another HTML-lint はXML(J)を解釈できないので、XMLに対して文法チェックしてもあまり意味がありません。実際には、"<?" はXMLに限らず、一般のシステム依存の何かの処理命令を示すマーク付けです。HTML4.01(J)にあるように、一般的には処理命令を閉じるのは ">" ですが、XML宣言を閉じるのは "?>" です。
古いWWWブラウザなどは、処理命令がそのまま表示されてしまうことがあります。この警告は減点されません。
HTML中でのコメントは、"<!-- 〜 -->" と書きますが、この "〜" の部分に "--" を書くには注意が必要です。RFC1866(J)では、"--" と "--" の間がコメントとみなされ、その組が複数回現れてよく、それらの組と組の間は空白文字だけが書ける、となっています。つまり、次のような書き方は間違いです。
最初の例は、"--" が正しく組になっていませんし、次の例は組と組の間が空白ではありません。以下の例は正しいのです(ただしRFC1866として)。
Another HTML-lint では、このような正確な仕様を調べるのではなく、単純に余計な "--" が現れただけで警告するようにしています。しかし、多くのWWWブラウザでは、このようなコメント中のハイフンの扱いについては、相当寛容です。
HTML4.01(J)では、コメント中に 2個以上連なったハイフンは書かないように、とされています。XML(J)でも禁止です。つまり、上の例はすべて誤りです。
RFC1866(J)では、空のコメント "<!>" は、"--" がゼロ組のコメントとして正しいコメントとされています。でも、書かない方がいいでしょうね。混乱の元です。XML(J)にはこのような表記は存在しません。
<TITLE>中には、コメントも含めてテキスト以外は書かないようにとされています。HTML4.01(J)を見てください。
コメント中に `<` や `>` を書くと、いくつかのWWWブラウザを混乱させることがあります。 *
までをコメントとみなしてしまうものがあるそうです。これは、WWWブラウザが悪いというよりも、古いHTMLでこのような実装がされ得ていたようです。今時のWWWブラウザではこんなことはないようです。この警告は減点されません。
までがコメントとみなされて、残りが宙に浮いてしまいます。SGML的には「かんたら」の部分が非コメント部分とみなされてうまくありません。
仕様上は、"<!-- 〜 -- >" と書いてもいいことになっています(XML(J)では禁止)。しかし、逆に "<! -- 〜 -->" とすることは禁じられています。このときは、< とタグ要素名の間に空白が含まれていると警告されます。
読んで字の如くです。WWWブラウザによっては気を利かせて "--!>" の位置でコメントを閉じてくれますが、そうでない場合は、その後ろの記述がずっと無視されることになります。
"<!--" が現れたのに "-->" が最後まで現れなかったときの警告です。コメントを入れ子にしたりして、どこか間違えたのでしょう。
タグの開始は、"<TAG" のように続けて書かなければなりません。"< TAG" のように書いてしまうと、タグとして認めてもらえません。もしも、"<" を "<" という文字の意味で書いたのなら、それはそれで "&lt;" と書かなければなりません。これについては、実体参照に関する警告を参照してください。
特許出願用HTMLでは、これが許可されているのですが、あまりにもひどい許容なので、この場合でも警告されます。
予期せぬ `<` が <TAG> 内にあります。閉じられていないタグの可能性があります。 *6*
もっと本当のことを言えば、実はこれはSGML的には間違っているとは言えません。SGML宣言で SHORTTAG YES のときにはタグの連続で直前のタグの > を省略してもいいことになっているからです。HTMLはどれも SHORTTAG YES です。終了タグだって、それがどの開始タグに対応するか自明な場合は </> としてもいいとか、もっといろいろあるんですが、そこまで正しいSGML的解釈をWWWブラウザに期待できません。HTML4.01(J)などを見てください。
実際には、<br></br> と書いてもOKです。終了タグがないときの警告も参照してください。
/ は、要素名とはなり得ない文字なのですが、<br/> という記述に対して古いユーザエージェントは br/ を要素名とみなし、未知のタグということで無視してしまうようです。これを <br /> とした場合は、既知の br なのでちゃんと改行される。ということのようです。
XML(J)ではこの空白はあってもなくても構いません。メディアタイプが application/xhtml+xml である場合は警告されません。
XMLの Content of Elements(J)では、空要素タグは、<tag></tag> のように開始タグと終了タグをくっつけて書かなければならないとされてます。つまり、空白も含めることはできません。
タグには開始タグ <TAG> と終了タグ </TAG> の対で用いられるものが多くあります。このタグの要素として、何が書けて何が書けないかは明確に決められています。
HTML4.01 Strict(J)では、ブロックレベル要素とインライン要素の区別が厳格になっているので、「あれ? どうしてこれがエラーなの」と疑問に思うものが多いかも知れません。例えば、<BODY> や <FORM> 内に直接インライン要素を書くことができなくなっています。<A> や <INPUT> などはインライン要素なので、次のようなのは HTML4.01 Strict では誤りとなります。
DOCTYPEの意味をわからずに、「とにかくHTML4.0のやつ」と不用意に宣言している人はこの警告を大量に食らうことになります。そういう人は、とりあえずHTML4.01 Transitionalな宣言を付けましょう。そしてその意味を勉強してください。
<UL> や <OL> を入れ子にしてこの警告を受け、「<UL> って入れ子にできないんだっけ」と疑問に思われる方もいるようです。
「<TBODY> なんて聞いたこともないぞ」と驚かないでください。たいてい <TR> を忘れているために出るエラーです。
もうひとつの間違いとして、<NOFRAMES> を <HTML> 直下に書いていることがあります。多くの参考書でもそう書かれていますが、これは間違いです。正しくは、<FRAMESET>〜</FRAMESET> 内に書かなければなりません。しかもこの間違いを犯している参考書は、<NOFRAMES> ではなくて、<NOFRAME> と書いていることが多いようです。<NOFRAME> というタグは存在しません。いくらWWWブラウザが <NOFRAME> を許容しているとはいえ、正しいタグを書くようにしましょう。
Laura Lemay のHTML入門に、<PRE>〜</PRE> 内に <IMG> を書く例が載っているけど、現在のHTMLでは禁止されています。これはこの本の書かれた時点のHTMLが古いからです。と、思っていたのですが、HTML1.0でもそのようなことはできないことがわかりました。HTML+ではできるようです。
HTML4.01(J)での <INS> と <DEL> は、それらがどの要素中で使用されるかによって、書ける要素が違います。つまり、インライン要素として記述した場合はブロックレベル要素は書けません。
とりあえず書いても大丈夫ですが、薦められていません。将来的に書けなくなる可能性があります。この警告は減点されません。
タグによっては、ある条件で特定のタグの要素内にしか書けないものがあります。多くは内部に書けないと警告されますが、DTDで規定できない場合はこの警告が出ます。
これに関して、HTML+のDTDでは次のように定義されています。これは、DLの内容はひとつ以上の連続するDTにひとつのDDが続いた組がひとつ以上、と読みます。つまり、HTML+ではDDを続けることは禁止されています。
RFC1866(J)以降では次のように定義されています。これは、DLの内容はDTまたはDDがひとつ以上、と読みます。順序の規定は含まれていません。
HTML4.01(J)には、<DD> を連続させた例が載っています。ということは、HTML4.0では、DTDどおりに、こう書いても問題なしとなったんでしょう。HTML4.0以上では <DD> の連続に対してこの警告は出ません。
などというのでは、何のための <ADDRESS> なのかわかりません。特に、<P> を <BR> の代わりに改行の意味で使っていたりすると、</P> が省略されているとみなされて、さらにこの警告が出ることが多くなります。<P> は段落のためのタグであり、改行のためにあるのではありません。
としたのでは、Lynxなど一部のWWWブラウザではそこに飛べなくなってしまいます。文法的には間違っていないし、同じ場所に複数の名前を付けたりするのはよくやることだと思いますし、そもそもアンカーはその一点に指定するのであって、ある範囲に指定するのではありません。Lynxなどが飛べないのは、不具合に近いと思います。なお、最近のLynx(2.8.1)ではそのようなことはないようです。
あるWWWブラウザで半角空白と異なる振る舞いをするからといって、全角空白 □ を利用して、<P>□</P> のように空白だけの要素を書いて桁揃えをしようとする試みが数多く行なわれています。これは、偶然うまくいくかも知れませんが、好ましくありません。しかし、これらが何らかの別の正当な意図的な目的で行なわれていないとも限りません。ここでは、全角空白の他に、半角カタカナ空白である &#160; &#xA0; や、&nbsp; も含めて空白文字とみなしています。
<TD> などの内容を空白だけにして、何らかの視覚効果を狙うのは、スタイルシートで行なうようにと、アクセス指針CSS技術文書に書かれています。この警告は減点されません。
本質を理解しないまま満点を目指した結果なのですが、意図的に <P><BR></P> と書かないとも言いきれません。
チェックしているHTMLのヴァージョンではサポートされていないが、他のヴァージョンでサポートされているタグです。あまりこの警告が大量に出るようなら、DOCTYPE宣言が適切でない可能性があります。
このタグは、すたれつつあるタグです。将来はサポートされなくなる可能性があるので、使わないようにしましょう。例えば、次のように代替のタグを使います。
ただし、HTMLのヴァージョンによって警告されるタグが異なりますし、単純に要素名だけ替えればいいというわけではないので注意してください。
HTML4.01では、<FONT> や <U> などが薦められないタグになっています。これらのタグは、文書構造を記述するという本来の目的からは外れたタグとして、スタイルシート(CSS1(J)/CSS2(J))を利用しなさい、ということです。それにしては、<B> や <I> などは外されていません。
とはいっても、スタイルシートをサポートしてるWWWブラウザなんて最近のMozillaとMSIEくらいだし、そいつらもまともにはまだサポートしてないし、二の足踏んじゃいますね。-->この警告は減点されません。
<XML> は、HTML中にXMLを挿入するのに用いますが、Another HTML-lint ではXML名前空間等の解釈をすることはできません。<XML>〜</XML> 内に書かれるタグは、開始終了タグの対応関係以外はチェックされません。この警告は減点されません。
省略できない開始タグが書かれていません。ISO/IEC 15445 などでは、<HTML> を省略することができません。XHTML1(J)では、すべての開始タグは省略できません。
開始タグの省略は、HTMLではあまり行なわれないようですが、仕様上は省略が許されているタグがあります。<HTML> や <HEAD>、<BODY> などの開始タグは省略することができます。だからといって、省略はしないようにしましょう。
タグのひとつもないプレーンなテキストをHTMLとして評価しようとすると、省略可能なタグが補われて、次のようなHTMLだとみなされますが、<HEAD> に必要な <TITLE> が含まれていないので、正しいHTMLとはなりません。<TITLE> タグは省略可能ではないので、自動的に補うことができません。
HTML4.0で拡張されたタグのうち、古いヴァージョンとの互換のために開始タグの省略できるものがあります。例えば、HTML3.2(J)などでの次のようなTABLEがそうです。
省略可能である終了タグは、たくさんあります。HTML3.2(J)では、次の終了タグは省略して構わないことになっています。他のHTMLではまた違います。
これらのうち、多くの場合は省略して用いられる o の付いている 6種のタグ以外の終了タグを省略したときは、この警告が出ます。これらの終了タグは、積極的に省略せよ、という意味ではなくて、省略してもいいけどほんとは書いた方がいいんだよ、というものです。
</TR> が除外されています。HTML4.01(J)に挙げられている例の多くは省略されています。これは、Mozillaなどの一部のWWWブラウザが、</TR> 省略時にテーブルの入れ子などの処理を正しく行なえないのが除外の理由です。また、Mozillaとしてチェックした場合は、</TH> と </TD> も除外されます。
また、</P> が、過去との互換のために省略できるなどというのは間違いです。過去(HTML1.0)との互換性はありません。
のようなときは、<P> の書ける場所があまり限定されていないので、</P> を、このHTMLを書いた人がどこに想定しているのかあまり明確ではありません。
これは、どう見ても <BLOCKQUOTE> が <P> の中に書けると誤解している書き方です。これは次のようにしてください。
また、<P> を改行の意味で使用していることもあります。<P> は段落の意味のタグなので、これは好ましくありません。
このように、<P>〜</P> の間に書いてはならないタグを書いていることが多いので気を付けましょう。
<P> はパラグラフだ。パラグラフ中に引用など別のブロックを含めることは、上の金太郎の例もそうだが、よくあるであろう。例えば、
なんてのを、HTML文法に則って構造化しようとすると、<OL> を <P> に含められないので
という風に書くと思うけど、これは、どう考えてもおかしい、と感じているのは私だけではないようだ。自然な構造は、
</LI> や </DT> などの省略が自明な場合に出ます。上の解説を参照してください。この警告は減点されません。
のように用いているとき、この場合「ほにゃらら」の後ろの </P> は省略が自明だとみなされます。「へにょろろ」の後ろの </P> は、さらに <P> が続けば自明な省略とみなされますが、そうでない場合は自明とはみなされません。
Laura Lemay のHTML本では </LI> は存在しないものとして解説されているけど、この本が書かれた時点のHTMLがそうだったからに過ぎず、現在のほとんどのHTMLでは </LI> は存在します。これを鵜呑みにして </LI> を存在しないものとしているおばかな参考書もあるので気を付けましょう。
ところが、残念なことにHTML4.0対応を謳ったHTML入門第2版でも「<LI> に終了タグは存在しない」と書かれているので注意してください。このシリーズ、初版から内容の全面的見直しをしてないようだ。
開始タグ直後と、終了タグ直前に空白や改行を入れないようにしましょう、ということです。この例だと、古い多くのWWWブラウザでホットスポットを表現する下線が、イメージの右下に髭のように表示されます。
開始タグ直後の空白については、例えば <LI> 直後に入れた場合、実装によってはリストの先頭が不揃いになることがあるようです。しかし、HTML4.01(J)には空白を先行させている例が沢山載っています。
Introduction to HTML3.2(J)には、開始タグ直後の改行と、終了タグ直前の改行は無視されるようなことが書いてあります。つまり、上の <IMG> の例は等価でなければなりません。しかし、既存の多くのWWWブラウザはこれを守っていません。
HTML4.01(J)では、開始タグ直後の空白や終了タグ直前の空白は表示されると思ってはいけないようなことが書いてあります。そのとおりならば、
なんて書くと、単語が繋がってしまうはずなので、こんな風に書くべきでないということになります。これは次のようにします。
この警告は、状況を細分して減点したりしなかったり制御すべきなのですが、そこまでできていません。つまり、インライン要素の開始タグ直後の空白のみ減点し、他は非減点にすべきであろうと考えています。とりあえず、この警告は減点されません。
ほとんどの開始タグは省略できないので、それらの開始タグなしに終了タグは存在し得ません。開始タグを消したときの修正漏れの他に、タグの入れ子関係がおかしくなっているときの副作用のこともあります。
このような単純な間違いはいいのですが、タグの入れ子が深いときなど、ひとつタグを間違えただけで、この警告がたくさん出ることがあります。
この警告に出てくる <TAG> は、そのタグでエラーが起こったことを示すだけです。<TAG> だけ 100レベルも入れ子になっているわけではありません。
省略できない終了タグを書いていないときに警告されます。よく、</A> を書いていないことがあります。WWWブラウザによっては適当に </A> を補ってそれなりのリンクが張られるものもありますが、全然うまくいかない場合もあります。この </A> を書いていないケースでは、<A> の中に <A> を書いていると警告されることも多いです。
タグの要素名や属性名は、(いわゆる半角の)英数字、ピリオド "."、ハイフン "-" から成り、先頭は英字です。HTML4.01(J)では、下線 "_" とコロン ":" も書けるようになっています。属性値に空白など他の文字を含めたいときなどは引用符で囲む決まりです。タグ内の引用符の外側に、これら以外の文字があったときに警告されます。よくあるのが、ハイフン "-" と下線 "_" を間違えているケースや、属性の区切りに全角空白を書いていたり、属性名を全角にしているケースです。ひとつでもこういうのがあると、そのタグ内でこのエラーがたくさん出ます。
HTML中でこれらを大文字か小文字かどちらかに統一して書いていた方が美しかろう、という(多分に宗教臭い)警告です。要素名、属性名それぞれ独立にチェックされます。HTML4.01(J)のリファレンスでは、要素名は大文字、属性名は小文字で書かれていて、その理由は読み易くするためだ、と言ってます。
XML(J)では要素名や属性名の大文字小文字は区別されるので、どれでもいいというわけにはいきません。決められているとおりに大文字小文字のメリハリを付けて書く必要があります。XHTML1(J)では、要素名、属性名は小文字に決められているので小文字で書かなければなりません。
間違った属性が指定されています。スペルミスなどの可能性があります。しかし、参考書があからさまに間違った解説をしていないとも限りません。例えば、Mozillaを解説したある参考書では、<LAYER> に名前を付けるのにNAME属性を使うよう指導しています。Netscape社のサイトを見ればわかりますが、これはID属性の誤りです。
チェックしているHTMLのヴァージョンではサポートされていないが、他のヴァージョンでサポートされている属性です。あまりこの警告が大量に出るようなら、DOCTYPE宣言が適切でない可能性があります。
この属性は、すたれつつある属性です。将来はサポートされなくなる可能性があるので、使わないようにしましょう。ここで指摘される属性には、スタイルシートによる代替はありません。特に<A>のTARGET属性は、その利用自体が薦められていません。フレームの利用や、強制的な方向付けはやめましょう。
<TAG> の属性 `ATTR` はあまり薦められない属性です。スタイルシートを使いましょう。 *3*
スタイルシート(CSS1(J)/CSS2(J))での代替を薦められている属性です。残念ながら、これらの属性すべてがスタイルシートで置き換え可能なわけではありません(CSS2では可能?)し、スタイルシートをサポートしていないWWWブラウザのためには使わざるを得ないとも思います。この警告は減点されません。
タグによっては、必ず指定しなければならない属性のあるものがあります。HTML3.2(J)の <BASE> のHREF属性などがそうです。また、<AREA> のALT属性は必須です。<IMG> のALT属性はHTML3.2では必須ではないのですが、HTML4.01では必要な属性となっています。ALT属性の使用を促す警告も見てください。
RFC1866(J)では、属性と属性値とを区切る = の前後には空白を含めてもいいことになってるんですが、それをわざわざ警告するHTMLチェッカも存在するのでこの警告があります。この警告は減点されません。
属性値を引用符で囲んでいる場合、その中に ">" が現れると、タグが閉じられてしまう可能性があります。
と、実体参照を用いて書くようにしましょう。これについては、RFC1866(J)で言及されていて、本来は間違いとは言えないのですが、実際に引用符を閉じ忘れている場合との区別が厳密にはつかないため、Another HTML-lint では文法的な間違いとしています。
属性値の文字列を囲む引用符には、二重引用符 "〜" と単引用符 '〜' のどちらでも使用できます。これらの使い分けは、主に二重引用符自身を表現したいときに、いちいち &quot; と書くのがわずわしいので単引用符で囲む、というものです。
これらは、どちらも同じです。しかし、単引用符を解釈しないWWWブラウザが存在するそうです(MSIE for MacOS が該当します)。この警告は減点されません。
ところで、ある参考書に "〜" 中に " を書くには \" とするなどと書いたのがありました。どうしてそんな解説が書けるのか不思議でなりません。JavaScript中などとごっちゃになってるんですかね。
属性値を必ずしも引用符で囲む必要はありません(XHTMLを除く)。値が英数字、ピリオド "."、ハイフン "-" から成り(いずれも半角の)、72文字以内の文字列のときは引用符で囲む必要はありません(実際はこれらの制限はSGML宣言(J)の QUANTITY NAMELEN で行われて、HTML4.01では 65536です)。そうでない文字列は、引用符で囲まなければなりません。-5 は囲まなくてもいいですが、+5 は囲まなければなりません。Cプログラマの方は、下線 "_" が含まれていないことに注意してください。
と書かなければなりません。ただし、HTML4.01(J)では、名前文字に下線 "_" とコロン ":" が追加されているので、_top を引用符で囲む必要はないのですが、他のHTMLのことも考えれば囲んだ方が安全です。
HTML4.01(J)で、下線 "_" やコロン ":" を含む文字列を引用符で囲んでいないときにこの警告が出ます。他のHTMLのことも考えれば囲んだ方が安全です。
引用符で囲む必要のない裸で指定されている属性値に対して、注意を促します。これは、好みで全部囲まなきゃ気が済まないときなどにチェックするようにしましょう。それ以外ではたぶん不要です。この警告は減点されません。
これらが間違いかどうかはよく知らないのですが、文書記述言語SGML(内容は日本工業規格だからそれなりだけど、HTMLとしては無惨極まりない)の 6. 要素構造 によると、正しくないように読めます。
XHTML1(J)には、属性値の先行後行する空白は無視され、それ以外の連続する空白は単一の空白として扱われると書かれています。つまり、上の例はすべて正当です。
これらはいずれも正しくありません。<IMG alt=""> のように、空にできる属性もあります。
HTMLにおける属性値は 1024文字以内でなければなりません。これは、SGML宣言(J)の QUANTITY LITLEN で指定されるもので、HTMLごとに違っているのですが、1024に決め撃ちです。ちなみにHTML4.01では 65536です。
幅を示す WIDTH属性には、数字だけの他に、"50%" とか "3*" のような指定ができるものがあります。スタイルシートと混同してか、"180pt" のような単位を付けられるような誤解があるようですが、そのようなHTMLは今のところ存在しません。
フォームコントロールなどで指定する TABINDEX属性の値は、HTML4.01(J)で、0〜32767 の範囲に制限されています。
ID属性は、HTMLでは、属性名などと同じに、英字から始まり英数字とハイフン "-" とピリオド "." から成らなければなりません。HTML4.01(J)では、下線 "_" とコロン ":" が追加されました。小文字のIDに関する警告も参照してください。
XHTMLでは、英字または下線 "_" から始まり、英数字とハイフン "-" とピリオド "." と下線 "_" などから成らなければなりません。コロンは含まれまれないことに注意してください。XHTMLでは、ASCII文字以外もIDに利用できるのですが、Another HTML-lint ではチェックしていません。ASCII文字以外のIDはエラーになります。
BGCOLORなどの色の指定は、"#00FF80" のような特別な形式でRGBを指定するか、決められている色の名前を指定します。HTML3.2(J)やHTML4.01(J)では 16色に名前が付けられていますが、MozillaやMSIEでは拡張されていて全部で 140色に名前が付いています。
Another HTML-lint は、PROFILE属性を空白区切りの複数のURI列として評価します。この警告は減点されません。
XHTMLのID属性の値は、HTMLのそれとは異なっており、互換性もありません。下線 "_" から始まるID値は、XHTMLで使えますが、HTMLでは使えません。そのような値は避けるようにしましょう。
ごく一部の属性は、取り得る値が固定されているものがあります(DTDで#FIXEDが指定されているもの)。そのような属性では、固定されている値以外を指定することはできません。
<TAG> の ATTR は属性名と属性値が同一です。属性名を省略して属性値だけの指定にしましょう。 **
の属性名の compact= の部分を省略した書き方です(属性値を省略しているのではありません)。したがって、本来ならばこのような省略しない書き方もできるはずなのですが、こういうのを解釈しないWWWブラウザもあるようです。省略した書き方をするようにしましょう。
属性値の引用符を省略できないXHTML1(J)では、属性名を省略した短縮形を書くことはできません。例えば、
の省略形です。こういうのは、他に center という値を取る属性が存在しないときに可能なのですが、ここまで省略形をきちんと解釈してくれるWWWブラウザはなかなかないようです。
実体参照というのは、&lt; や &#38; みたいな書き方のこと(正確には後者は文字参照)で、テキスト中に "<" や ">" など直接表現できない文字を書くときの方便です。実体参照は "&" で始まって ";" で終わります。SGMLでは、終わりのセミコロンは、省略が自明な場合は書かなくてもいいことになっています。例えば、
なんていうのは、OKなんですが、HTML4.01(J)ではそんな省略はしないようにと書かれています。
大文字小文字の区別されるXHTMLでは、16進数の文字参照も &#x と小文字で始めなければなりません。&#X1234; は誤りです。
"<" や ">" など実体参照で参照される名前は、HTMLごとに決まっています。大文字小文字が区別されるので、"&amp;" のつもりで "&AMP;" と書くことはできません。WWWブラウザによっては同一視しているものもあるようですが、本来は間違いです。また、
CGI呼び出しでのパラメタ区切りは歴史的に & です。この & も &amp; と書かなければならないことに注意してください。
としなければなりません。& のままで動作するのは偶然です。上の例では、たまたま &bar という実体が定義されていないからに過ぎません。
CGI呼び出し中でも実体参照を用いなければならないことは、RFC1866(J) 8.2.1 や、HTML4.01(J)などに書かれています。これにからんで、パラメタ区切りは "&" じゃなくて ";" にしましょうとも書かれていますが実際そうなりつつあるんでしょうか。少なくとも、Perlの非標準のライブラリ cgi-lib.pl や、標準の CGI.pm は、比較的新しい版ならどちらの区切りでも受け付けてくれます。
プロバイダ指定のCGIを利用する場合、この "&" を実体参照で解説しているものはまずありません。言われたとおりに書かなけりゃ動かないと脅されていると思いますが、"&amp;" と書き直してみてください。動くはずです。これは、CGI側の制約ではなくWWWブラウザ側の問題だからです。ちなみに、古いOmniWeb1.0ではURL中の実体参照が展開されないそうです。
&#38; のような文字参照で参照できる文字コードは、HTMLごとに定められています。例えば、HTML2.0やHTML3.2では 255まで、HTML4.0では 1114111までです。これはSGML宣言に記述されています。これより大きな値を与えると警告されます。MozillaやMSIEではチェックされません。DTDが存在しないからです。
<SCRIPT> など一部のタグの要素を除いて、"<" や "&" などをテキスト中に直接書くことはできない、と思ってください。つまり、書きたければ実体参照を用いて、"&lt;" や "&amp;" と書きます。<PRE> 中にはそのまま書けると思っている人もいるようですが、<PRE> 中でも実体参照を用いなければなりません。
のように書くと、この "&" は実体参照ではないのが明らかなので、正しく "&" と表示されます。これはSGML的に誤りではないのですが、ちゃんと実体参照を用いて書くようにしましょう。
安全のために、テキスト中の引用符 " を実体参照を用いて表現するように促す警告です。実際にはその必要はありません。この警告は減点されません。
<HTML> には、LANG属性を使ってその文書の言語を明示しておくことがWAIで薦められています。日本語の場合は次のようにします。
HTTPレスポンスヘッダ中で Content-Language によって言語コードが指定されている場合は警告されません。
XHTML では xml:lang属性を使いますが、XHTML1.0では、両方を書くように薦められています。
XHTML で lang属性と xml:lang属性の両方を併記したとき、その値は一致していなければなりません。
WAIで、言語の変化をLANG属性で明示するように促されていますが、ここでは日本語の指定 LANG="ja" や LANG="ja-JP" 以外が指定してあるときに、属性値に日本語が含まれているかどうかを調べています。例えば、
というような場合です。また、属性の指定は、順不同でそのタグ内から有効となる(と明記されている)ので、
本来、言語の指定と文字コードは無関係なのですが、Another HTML-lint は主に日本語で書かれたHTMLを対象にしているので、このように文字コードによる判定を行なっています。
WAIで、言語の変化をLANG属性で明示するように促されていますが、ここでは日本語の指定 LANG="ja" や LANG="ja-JP" 以外が指定してあるときに、テキストに日本語が含まれているかどうかを調べています。ただし、<SCRIPT>〜</SCRIPT> 内などは除きます。
本来、言語の指定と文字コードは無関係なのですが、Another HTML-lint は主に日本語で書かれたHTMLを対象にしているので、このように文字コードによる判定を行なっています。
Lynxなどの一部のWWWブラウザは、この情報を解釈して、このメールアドレスへ直ちにメールを出したりできます。HTML作者を明示するためにも、このタグは入れるようにしましょう。
と、指定を薦めているにもかかわらず、HTML4.01では、リンク形式に MADE は含まれていません。また、指定があれば mailto: である必要もありません。この警告は減点されません。
ここでは、次のナヴィゲーション用のリンク形式の指定をチェックしています。どれも指定されていないときに警告されます。
LynxやMosaicなどの一部のWWWブラウザはこれらを解釈することができます。このナヴィゲーション情報についてはWAIで用意するように指示されています。この警告は減点されません。
しかし、HTML4.01(J)からは、こういった大文字小文字に関する記述がきれいさっぱり削除されてしまっています。この警告は減点されません。
"NOARCHIVE" は、ロボットを排除する値としてよく利用されていますが、robotstxt.org の仕様には含まれていません。
現在日本語で書かれているHTMLの多くには、文字コードとして JIS、Shift JIS、EUC が利用されています。UTF-8 なども見られます。HTMLがどのコードで書かれているのかを明示するために、このタグを書くようにしましょう。
これらのどれか適切なものを書けばいいのです。こうしておくと、よくできたWWWブラウザでは、文字コードのエンコーディング指定が欧米などになっていても、正しく日本語が表示されます。Mozillaなどでは、表示するフォントを指定されている文字コードごとに指定できるようになっています。<META> で文字セットを指定していると、それに対応したフォントで表示してくれます。
また、<META> での文字セットの指定がない場合、文字コードのエンコーディング指定を日本語(自動判別)にしてあると、Shift JIS と EUC の誤認識をすることもまれにあるようです。
RFC1866(J)によれば、本来は、この <META> の情報は、HTTPサーバが解釈して適切なHTTPレスポンスヘッダを生成できるようにするためのものなのです。つまり、WWWブラウザのためのものではありません。レスポンスヘッダ中に正しい文字セット指定があれば、WWWブラウザは何の問題もなく正しく表示できるはずなのです。が、(現在の)多くのHTTPサーバはそんな面倒な処理はしないので、なかなかうまくいかないようです。
HTTP1.1 (RFC2068) では、HTTPレスポンスヘッダにCHARSETパラメタを含めることが義務付けられています。こうなると、HTML中での <META> での文字セットの指定は無用の長物と化します。<META> による指定と、ビットパタンによる文字セットの推測は、正しくCHARSETパラメタをHTTPレスポンスヘッダに含めない日本のための過渡的な救済措置なのだそうです。XML(J)では、文書中の指定は無視され、CHARSETパラメタが必須です。詳しくは「charsetパラメタの勧め: HTMLにおける文字符号化スキームの明示方法」を参照してください。
ただし、これらは、HTTP経由での送受信を前提とした話なので、ローカルなHTMLには適用できません。ローカルなHTMLでは、CHARSETの指定は <META> で行なって構わないようです。が、<META> が正しく解釈されるのかどうかは別問題です。
一部のサーバでは、ファイル名の拡張子による Content Negotiation を導入しています。これは例えば、
とあった場合、WWWブラウザの言語の設定によって hello.html という要求に対してどちらかを自動的に振り分けて送信するものです。Asahiネットでは、さらにこの言語優先機能に加えて実験的にリソースの文字セットの指定も行なえるようにしています。HTTPサーバがリソース中の(METAタグによる)情報を参照してCHARSETを決定するのはたいへんなので、このやり方はなかなか利に適っています。文字セットは次のように明示することができます。いずれも hello.html という要求で済みます。
これによって、サーバはHTTPレスポンスヘッダに適切なCHARSETパラメタを含めるので、HTML中の <META> による指定は不要です。興味のある人は、Asahiネットだからできるリソースの多次元的表現について などを参考にしてください。
蛇足ですが、あるURIが特定のリソースを指すわけではないことが、これらから明らかなことに注意してください。ひとつのリソースを複数のURIで指し示すことも可能なので、リソースとURIは多対多の関係にあります。決して一対一ではありません。
よく、"charset=x-sjis" や "charset=x-euc-jp" を見かけますが、これらは、IANAには登録されていません。しかし、一部の古いWWWブラウザは、これらは解釈するけどIANAに登録されているやつは解釈しないというのもあります。Mozilla2.0などは、x-sjis は解釈するけれど Shift_JIS は解釈しません。これは、Shift_JIS の登録前に開発されたものだからです。日本語文書文字セットの指定方法などを参考にしてください。
登録前の文字セットの拡張として用いられる x-sjis、x-euc-jp などの x- で始まるものに関しては減点されません。
CHARSETの指定はなくてもいいのですが、RFC1945やRFC2068によると、指定しなかった場合は、ISO-8859-1が仮定されることになっています。日本語を書く場合はきちんと指定しなければなりません。
これは、RFC2070(J)やHTML4.01(J)に、もっとくどくど書かれていますが、ここでは単純にCHARSETが指定される前はASCIIしか書けない、と割り切ってしまっています。CHARSETで文字コードが指定されて始めて、そのリソースがどの文字コードで書かれているかわかるのです。<TITLE> で日本語を使っている場合は <META> よりも後ろに持って行ってください。
この警告は、<HEAD>〜</HEAD> 内のみのチェックです。HTTPレスポンスヘッダにCHARSETパラメタが含まれている場合は警告されません。また、メディアタイプが application/xhtml+xml である場合は警告されません。
改行やタブ、JISのエスケープシーケンスなど以外の制御文字(0x00〜0x1F)が含まれているときに警告されます。
CHARSETにShift JISが指定してあるときに、半角カタカナ(JIS X 0201 のカタカナ部分)が含まれていると警告されます。また、JISのときは ^[(I という半角カタカナ用のエスケープシーケンスが現れると警告されます。EUCでも半角カタカナが表現できますが、チェックしていません。^[(I というエスケープシーケンスは、ISO-2022-JPでは規定されていません。つまり、ISO-2022-JPと宣言しておいてこのエスケープシーケンスを用いるのは誤りです。
なぜ半角カタカナがだめなのかは、RFC1468や半角カナの危険性やなぜ半角カナは嫌われるのか(メモ)などを参考にしてください。
NTT DoCoMo iモード、特許出願用HTMLでは、半角カタカナの使用が許可されています。この場合、警告はされますが減点されません。
日本語のCHARSETが指定されているときや、CHARSETは指定されていないが日本語文書と判断されるとき、JIS X 0208:1997 で字形が例示されていない全角文字が含まれていると警告されます。例えば、丸付き数字やローマ数字、(株)などです。
ここら辺の話については、情報交換用漢字符号系 JIS X 0208、日本語と文字コードや、使ってはいけない文字などを参考にしてください (注意: 84-5と84-6は、X 0208-1990 で追加されたので、X 0208-1983 を解説している文書には現われていません)。
NTT DoCoMo iモードでの絵文字や、特許出願用HTMLでの使用が許可されている一部の丸付き数字の場合は警告されません。
指定されている文字コードセットは `XXXX` ですが、実際のコードは YYYY のようです。 *5*
せっかくCHARSETで文字コードを指定してあるのに、実際には異なる文字コードでHTMLが記述されています。このような文書は、CHARSETを正しく解釈するWWWブラウザではまったく読むことができません。日本語の指定(JIS、EUC、Shift JIS、UTF-8)のみチェックしています。XML宣言中のencoding指定の方が優先します。HTTPレスポンスヘッダにCHARSET指定がある場合は、さらにそちらを優先します。
HTTPレスポンスヘッダでCHARSETが指定されている場合、その指定と <META> で指定されているものが矛盾しています。あるいは、XML宣言でのencoding指定と矛盾しています。日本語の指定(JIS、EUC、Shift JIS、UTF-8)のみチェックしています。
本来CHARSETの指定は、HTML中の <META> で明示するものではなく、HTTPレスポンスヘッダで行なわれるべきものなのですが、これはサーバ側で面倒をみなければならず、HTTPレスポンスヘッダにCHARSET指定を含めていないサーバは多数存在します。詳しくは「charsetパラメタの勧め: HTMLにおける文字符号化スキームの明示方法」を参照してください。
XHTMLでは text/xhtml だと誤解されている方もいらっしゃるようですが、それは違います。そのようなメディアタイプは定義されていません。
指定されているメディアタイプ xxxx/xxxx は YYYYYY には指定しないようにしましょう。 *3*
HTML4.01(J)には、スクリプトを使用する場合は <META> 内にベースとなるスクリプト言語を明示しておくように書かれています。
のように、<SCRIPT> が現れる前に宣言します。個々の <SCRIPT> に指定する言語は、必ずしもこれと同一である必要はありません。
この警告は、<STYLE> タグに対する警告で、他のタグ中に埋め込む STYLE 属性に対してはもっと厳しい警告が出ます。ONCLICK 属性などに対しても同様です。
スクリプトのイベント処理で利用する ONCLICK だとか ONBLUR だとかの属性を利用するときは、<META> でそのスクリプト言語を指定しておかなければなりません。このことは、HTML4.01(J)に明記されています。Javascriptならば、
いろいろなタグの属性として埋め込まれる STYLE 属性を利用するときは、<META> でそのスタイル言語を指定しておかなければなりません。このことは、HTML4.01(J)に明記されています。CSSならば、
というような宣言を含めておきます。HTML4.01(J)には、指定がない場合は text/css が採用されることが期待できるように書かれているのですが、指定しなくてもいいわけではありません。
HTML4.01(J)では、HTTP-EQUIV 属性は NAME 属性の代わりとして使われるものとされています。つまり、これらを併記することはできません。
<META> には、CONTENT 属性が必要ですが、HTML4.01(J)では、META要素は名前と値とを対で指定するように書かれています。つまり、CONTENT 属性だけでなく、HTTP-EQUIV 属性または NAME 属性が必要です。このような、どちらかが必要という指示は、DTDでは表現できません。
スクリプトのイベント処理では、装置非依存性を確保するために、次の属性は対で使用するように、アクセス指針技術文書4.12.2(J)で薦められています。
WAIでは、REFRESHによる自動的なページの更新は行なわないように書かれています。これは、利用者の意思が無視されてしまうのが主な理由です。
自動書き換え機能をサポートしていないユーザエージェントのために、通常のリンクなどによって移動できるようにしておく必要があります。このことは、HTML4.01(J)に記述されています。しかし、WAIでは、そもそもREFRESHによる自動的な方向付けを行なうことを推奨していません。
これは、どちらが正しいのでしょうか。規定などはなく、どちらも正しいのでしょうか。問題は、"URL=jump.html" というのがURIとして正しいので、両者が正しいとするとあいまいさが生じてしまいます。Another HTML-lint では、とりあえず、区切り文字が "," か ";" かで区別するようにしてあります。
<SCRIPT>〜</SCRIPT> 内には、JavaScript など、HTMLとは構文上無関係な構文のテキストが含まれます。<SCRIPT> タグを解釈しないWWWブラウザも多いため、もし何の工夫もしないと、JavaScript などのプログラムがそのまま表示されてしまいます。そこで、JavaScriptでは次のような書き方をします。
ここで、コメント末の --> がJavaScriptのコメント // の後ろにあることに気を付けてください。// を書かないで --> だけだと、-- がJavaScriptの演算子に解釈されて、構文エラーになってしまいます。JavaScriptの演算子 -- は、HTMLのコメント中でうまくない振る舞いをするかも知れませんが、おそらくWWWブラウザは、コメント中の -- をHTMLの仕様書とは違う実装で処理しているので大丈夫なのでしょう。HTML4.01(J)では、コメント中に -- は書かないようにとされています。これは、このようなCDATA中の -- を考慮してのことかも知れません。
スクリプトとしては、<!-- は、その行末までが無視されるので、次のようなことが可能だとしている参考書があります。
<NOSCRIPT> はあとから追加されたので、古いWWWブラウザではサポートされていないことがあり、<NOSCRIPT> を使わなくても、<SCRIPT> 非対応のWWWブラウザのことを考慮できるということなんですが、"</" を <SCRIPT> 中に書くことはできないので、あまりたいしたことはできません。つまり、上の例は正しくありません。
<STYLE>〜</STYLE> に対してもこのエラーが出ます。この場合は、単純に内容をすべてコメントで囲めばいいのです。
また、そのためにそもそもコメントで囲む記述をすること自体が問題となります。外部にファイルを用意するよう促す警告を見てください。
のようなやり方も有効です。また、例えばJavaScriptのコメント内だからといって例外ではありません。
HTML4.01(J)には </ にアルファベットが続くときに終わりとなると書かれていますが、Another HTML-lint ではそこまでは見ていません。
HTMLで、<SCRIPT> や <STYLE> 内に、次のような文字を書くときは、外部にスクリプトファイルやスタイルファイルを用意するようにしましょう。
-- が含まれているために、全体をコメントで囲むようなテクニックも危険なものになっていることに注意してください。XHTML以外ではこの警告は減点されません。
XHTMLでは <SCRIPT> や <STYLE> の内容が #PCDATA です。コメントはコメントとして解釈されてしまうので、旧来のテクニックは使えません。外部にスクリプトファイルやスタイルファイルを用意するようにしましょう。
この警告は、WAIで守らなければならない事柄とされています。<NOSCRIPT> はあとから追加されたので、Mozilla2.0などの一部の古いWWWブラウザでは <SCRIPT> はサポートするけども <NOSCRIPT> をサポートしていないことがあります。このようなときは、スクリプトが有効なときでも <NOSCRIPT> 内が表示されてしまうことに注意してください。
また、WAIに示されているのは、重要な情報や機能を持っているスクリプトに対して <NOSCRIPT> を用意しなさいということです。実際にはONCLICKなどの表示を伴わないイベント処理に使われることも多く、これに対する <NOSCRIPT> が必要かというと、必ずしもそうとは言えません。というわけで、この警告はWAIで必須とされているにもかかわらず減点されません。
仕様上は文字数制限などないのですが、あまり長いタイトルはWWWブラウザによってちょん切られることがあるそうです。しかし、最低でも 64文字は可能なように、とのお達しがRFC1866(J)にあります。HTML4.01(J)にはこのような記述は見当たりません。
多くのHTMLで、<BODY> で指定できる色の属性には、BGCOLOR、TEXT、LINK、VLINK、ALINK があります。MozillaなどのWWWブラウザでは、これらを無視して独自に指定できるものもあります。このとき、HTML中の指定が中途半端だと、WWWブラウザでの指定とを混在させたときにうまくないことがあります。例えば、<BODY bgcolor="white"> とだけ指定してある場合、WWWブラウザ側で黒地に白字なんて指定になっていると、そのHTMLがまったく読めないという事態に陥ります。このようなことを避けるため、色指定をする場合は、なるべく全部を指定するようにしましょう。HTML4.01(J)にも似たような注意書きがあります。
スタイルシート中で色指定している場合も似たようなことが起こり得るので注意してください。Another HTML-lint では、スタイルシートの内容まではチェックできません。
<BODY> で背景画像を指定してあるとき、そこに書かれている文字はその背景画像上でうまく読めるように選ばれているはずです(意図的に背景に溶け込ませることもありますけど)。このとき、BGCOLOR属性を指定していないと、WWWブラウザが画像を表示しない設定などになっていると、その文字が読めなくなってしまう可能性があります。
のような場合、背景画像の読込みでうまく文字が読めるようになるのでしょうが、背景画像を表示しない(できない)環境では、文字が全く読めなくなってしまいます(意図的に読めなくしていることもありますけど)。警告は、背景画像の指定とは無関係に行なわれます。また、
ここで、前景と背景の明度差が 125未満のとき、または色差が 500未満のときにコントラスト不足として警告されます。
各タグに付けることのできるID属性は、ひとつのHTML中で重複した名前を付けることはできません。また、ID属性の値は、HTMLでは大文字小文字区別されません。XHTMLでは区別されます。
HTML4.01での <LABEL> のFOR属性などの値は、他のタグのID属性として指定されていなければなりません。
<FORM> の要素である <INPUT> や <TEXTAREA> などは、NAME属性で名前を付け、その設定情報をVALUE属性の値と対で、CGIなどに渡せるようになっています。TYPE=TEXTなどのように、VALUE属性の値が固定的でないものに対して、同じ名前の要素がひとつのFORM内で複数存在すると、CGI側ではそれらを区別できません。
しかし、HTML4.01(J)には、チェックボックスとラジオボタン以外のフォームコントロールについて、NAME属性の一意性について何も言及がありませんが、RFC1866(J) 8.1.2.7 にはSUBMITで同じNAMEを使ったような例があります。つまり
<FIELDSET> の直後には普通のテキストが書けることになっていますが、ここには空白以外を書くことはできません。これはDTD中にコメントされています。次はHTML4.01のDTDからの引用。
<INPUT type="radio"> で、同じ名前のラジオボタン、つまり同じグループのラジオボタンに付けられるチェックはひとつだけです。
<INPUT type="text"> や <TEXTAREA> には、何か初期値となるようなテキストをあらかじめ書いておくことがWAIで薦められています。その理由に、空だと正しく処理できないWWWブラウザの可能性が示されています。
HTML4.01(J)では、<BUTTON> にイメージを貼り付けるとき、それをイメージマップにすることはできないことになっています。ISMAP も同様です。
フォームコントロールをラベル付けするには何通りか方法がありますが、<LABEL> の要素にフォームコントロールを直接含めてしまうやり方があります。このとき、<LABEL>〜</LABEL> 内には、ひとつのコントロールしか含めることができません。HTML4.01(J)を見てください。
<LABEL> はフォームコントロールに付加属性を付けるためのもので、どれかひとつのフォームコントロールと関連付けられていなければなりません。その方法は、<LABEL> の要素に指定する方法と、FOR属性によってフォームコントロールのID属性と関連付ける方法があります。つまり、FOR属性のない <LABEL> は、要素の内容にフォームコントロールを含んでいなければなりません。
<LABEL> の要素にフォームコントロールを書いたとき、そのフォームコントロールはその <LABEL> に関連付けられることになっていますが、そこにさらにFOR属性やID属性を指定したときにどのように解釈されるのかについて、HTML4.01(J)には言及がありません。
FORもIDもない場合仕様上は問題なさそうですが、多くのWWWブラウザ(MSIE5〜6、Netscape3〜7、Opera6など)では、このラベルはフォームに関連付けられないようです。
FORだけある場合ラベルが他の ID="A" を持つフォームコントロールと関連付けられると思われ、そうすると内容に書かれたフォームコントロールはラベルに関連付けられなくなり、好ましくないと思われます。
IDだけある場合フォームコントロールは外側のラベルと、他の FOR="A" を持つラベルに関連付けられます。ひとつのフォームコントロールに複数のラベルを関連付けることは間違っていません。
FORとIDがあって食い違っている場合ラベル要素としてフォームコントロールを書いている意味がなく、好ましくないと思われます。
この解釈は間違っているかも知れません。k16@chiba.email.ne.jp までご指摘ください。
WAIには、<A> にも条件付でTABINDEX属性を付けるように書かれていますが、ここでは除いています。
指定するキーの一意性に関しては、HTML4.01(J)には記述されていません。ユーザエージェントによっては、同じアクセスキーを持つコントロールは、それらの中で次々と移動するように実装されているようです。しかし、17.11.2(J)には、<A> では直ちにリンク先に飛び、ラジオボタンの状態も直ちに変化する、ようなことが書かれています。これは、アクセスキーはアクションを起こすためのもので、コントロールの移動を行なうためのものではないということです。同じアクセスキーが指定された場合の議論がないのはどういうわけでしょうか。
ラベルと関連付けられているフォームコントロールでは、フォームコントロール自身にACCESSKEY属性がなくても、ラベルにあればいいことに注意してください。ラベルとフォームコントロールの関連付けの方法は、<LABEL> の要素としてフォームコントロールを書く方法と、<LABEL> のFOR属性とフォームコントロールのID属性で関連付ける方法があります。これについては別の警告のところに解説があります。
関連付けられたラベルとフォームコントロールにACCESSKEY属性を指定するときの組み合わせは次のようになります。
両方にあってキーが食い違っている場合どちらのキーでもそのフォームコントロールにフォーカスを移すことができるようになるのかも知れません。正しくない指定なのかも知れませんが、とりあえず警告されません。
この警告は減点されません。<FRAMESET> や <FRAME> に関しては、書かなければならないとされていて、違う警告が出ます。
<APPLET> に ALT 属性と等価な内容の両方を書くことは薦められていません。 *3*
<APPLET> は <OBJECT> と同じように、要素の内容に適当な説明を書くように求められています。しかし、<APPLET> にはALT属性があるので、内容説明に加えてALT属性で説明を書くと、WWWブラウザはどちらを採用していいのかわかりません。つまり、どちらか一方にするように、アクセス指針技術文書4.8.1(J)に書かれています。
<TAG> の ALT 属性に空白だけの文字列を指定することは薦められていません。 *3*
アクセス指針技術文書5.6.1(J)には、空白だけのALTを指定して、イメージを表示しないときにうまく隙間が空くようにした次のようなのはだめ、と書かれています。
Another HTML-lint では、このような語の途中での指定だけでなく、常にチェックされます。
イメージが表示できないWWWブラウザも数多く存在します。また、表示ができるWWWブラウザでも、自動的にはイメージを読みに行かないような設定にしてあることもよくあります。そのようなとき、そこにどのようなイメージが貼り付けてあるのか、適切なコメントがあると、表示されたテキストがぐっと読み易くなります。どのようなコメントが適切かは多くの人がいろいろな意見を述べていますが、宗教色の濃い議論もあるので注意が必要です。ここでは、特に指針は示しませんが、空の指定 alt="" も、それなりに有効な場合があることだけは覚えておいてください。WAIの解説(J)を参照してください。
<IMG> 以外でも、この警告は出ますが、ALT属性はHTML4.01ではほとんど必須属性です。
<INPUT type="image"> はイメージのボタンを作ります。ところがこのタグにはALT属性がありませんでした。HTML4.0でようやくALT属性が指定できるようになりました。
イメージのサイズを指定しておくと、WWWブラウザが実際にそのイメージを読みに行かなくても、他のテキスト部分のレイアウトを行なうことができます。これは、ネットワークの負荷を軽減し、迅速な表示が行なえることを意味します。
<INPUT type="image"> はイメージのボタンを作ります。ところがこのタグにはWIDTHやHEIGHT属性がないので、どうしてもイメージの読み込みが起こります。HTML4.01にもありません。
プロバイダ指定の <IMG> を利用するアクセスカウンタCGIなどの中には、イメージの幅が特定できないものもあります。当然そのような場合にはWIDTHを指定することはできません。いや、指定してもいいですが、イメージがゆがむかも知れません。
ISO/IEC 15445 では、<IMG> にISMAPとUSEMAPの両方を指定してはならないと明記されています。HTML4.01などにこのような記述はないのですが、両方指定するのはおかしいので、どのHTMLでも警告されます。
<IMG ISMAP> でのサーバサイドイメージマップは使わず、クライアントサイドイメージマップを使いましょう。 *4*
サーバサイドイメージマップを使っていると音声出力などでいろいろ不便があったりするため、クライアントサイドイメージマップを利用するようにWAIで強く薦められています。
アクセス性向上のために、<TABLE> には、SUMMARY属性を使って要約を付けておくことがWAIで薦められています。
アクセス性向上のために、<TH> には、ABBR属性を使ってヘッダラベルの省略形を付けておくことがWAIで薦められています。ただ、もともと省略形の内容の場合など、闇雲にABBRを付けるのは無意味なのですが、そのような識別が Another HTML-lint ではできません。この警告は減点されません。
フレーム機能をサポートしていないWWWブラウザも多いため、<NOFRAMES> を指定して、そういうWWWブラウザの便宜をはかってあげましょう。<NOFRAMES> を間違ったところに書いていたりスペルミスをしていないかもチェックしましょう。特に、<NOFRAME> と S が抜けていることが多いようです。
とはいえ、<NOFRAMES> があればいいというものでもありません。文法的には非の打ち所がないのですが、
などというおばかなことはしないようにしましょう。このようにメッセージされても、その人が指示に従えるとは限りません。
<FRAME> の SRC 属性で直接イメージなどを指定することは薦められていません。 *4*
<FRAME SRC> でイメージなどを直接指定することは、WAIでは行なわないようにとされています。アクセス指針技術文書4.10.4(J)は、FRAMEにはHTML文書を、ということなんで、HTML以外を指定することは避けましょう。
フレームターゲットに同じ名前を付けることはできません。でも、HTML4.01にそのことが書いてあるんでしょうか。
このような名前を付けることはできません。というか、一般に付けられる名前の制限はもっときついです。次の警告を見てください。
は、同じはずなのですが、一部のWWWブラウザは異なるターゲットとみなしてしまいます。予約されているフレームターゲットは小文字で書くようにしましょう。
HTML4.01(J)には、フレームターゲット名は英字から始まらなければならない、そうでない名前は無視される、と書かれています。これは、かなり厳しい制約で、将来増えるかも知れない(_topなどの)予約名に対処するためのものだと思われます。しかし、Mozillaなど、HTML4.0に先行してフレームを実装していたWWWブラウザではこのようなことはないようです。
文字フォント修飾のタグには、物理的なものと論理的なものがあります。物理的なものというのは、太字の <B> のように直接的なもので、論理的なものというのは、強調の <EM> という意味的なものです。SGMLの精神からは、なるたけ意味的な表現をするように心がけましょう、といったところなんですが、なかなかそうもいきませんね。WAIでも使わないように薦められています。この警告は減点されません。
顔文字などを <TT>:-)</TT> などと書くことも多いでしょう。このようなのはASCIIアートと呼ばれていて、WAIでは複数行に渡るようなASCIIアートは飛び越せるような工夫が必要とされています。
<P> を行末に書いているときにこの警告が出ます。<P> は改行するためのタグではありません。<P> を行末に書いていたのは、HTML2.0より前の大昔のことです。RFC1866(J)では段落のためのタグとして、終了タグを伴って定義されています。
かなり多くの参考書が、<P> を改行するためのタグだとか、1行空けるためのタグだとか紹介しています。それは嘘です。そんなことを堂々と書くような著者は信用してはいけません。自分では調べもせず、間違いの書かれた二次文献や三次文献などからの引用で済ませているからだと思われます。
文書構造を無視して整形目的で <BR> を利用しているようなとき、<BR> が頻繁に連続して現れます。この警告を回避するために <BR>&nbsp;<BR> などというお馬鹿なことはくれぐれもしないようにしましょう。
また、Lynxなどの一部のWWWブラウザは、連続する <BR> をひとつにまとめてしまうことがあります。
<PRE>〜</PRE> 内にタブ文字を書くことは避けるように、HTML4.01(J)で強く要請されています。タブ文字は空白文字に置き換えられて表示されるのが普通ですが、モノによって期待通りの結果を得られないことがあるというのが理由です。つまり、<PRE> の整形済みという主旨に反するということです。
HTMLには、章や節を直接表現する構造はありませんが、見出し用のタグ <H1>〜<H6> が用意されています。本来、これらの出現順序関係については、何の制約もありません。この警告は、<H2> の次に <H4> が来たら何かおかしいんじゃないの、という程度のものですが、このような使い方はRFC1866(J)では推奨されていません。
また、これらを文字サイズ調整の意味に使っていたりするのを防ぐ効果も多少あります。多くの参考書が、<Hn> を文字サイズ調整のタグだと紹介しています。それは嘘です。ついでに、<Hn> は、ヘッダ(header)ではありません。見出し(heading)です。これも参考書がよく間違っています。
このようなイメージに対して、<A>の場合はWAIで指摘されているのですが、見出しに対して特に何か言われているわけではありません。しかし、<A>の場合と同じように好ましくないのには変わりないでしょう。
この警告は <A> に対するもので、他方はそれ以外に対するものです。<A> を別扱いしているのは、WAIでも「重要なリンクに対して」というただし書きが付いているからで、全部の <A> に対してACCESSKEY属性を要求するものではないからです。Another HTML-lint は、どれが重要なリンクかを判断できません。
アクセス性向上のために、リンクとリンクの間は、何か印字可能な文字(空白でもよい)で区切ることがWAIで薦められています。例えば、
D-リンクと呼ばれるこの技術は、旧式であまり薦められません。詳しくはアクセス指針技術文書3.2.2(J)や4.7.2(J)を参照してください。
次のように、同一の内容で異なるリンク先を示すのは、アクセス指針技術文書4.6(J)で好ましくないとされています。
もし、このような必要性に迫られたときは、異なるTITLE属性を付けて区別するように薦められています。
アクセス指針技術文書4.6(J)などによれば、例えば、目の不自由な方がページを読むとき、リンク部分だけを拾って読んだりすることがあるそうです。そのようなとき、
とかいったリンクでは、意味がわかりません。もっと意味のある文章にしましょう。「ここ」だけじゃなくて「こっちのサイト」とか「このページ」とかいうのも引っかかります。一部の代表的なものしか引っかかりませんが、意図しないものも引っかかってしまうかも知れませんので、そのようなときは k16@chiba.email.ne.jp までお知らせください。
また、「クリック」というリンクもよくないとされています。なぜなら、リンクをたどる動作はクリックとは限らないからです。「押す」という用言も同様です。
アンカー名にはどんな文字を使ってもいいことになっているのですが、まあ、空白は使わない方がよかろう、ということです。アンカー名に安全でない文字を使った場合も参照してください。
として行ないます。NAME属性の値には何を書いてもいいことに注意してください。一方、このアンカーを参照するには、
のようにURIと一緒に指定します(RFC2396にはこのアンカー名部分はURIの一部ではないと明記されています)。一緒に指定するので、アンカー名にはURIとして正しくない文字は使ってはならない(本当か?)んですが、これは、NAME属性の性質と矛盾しています。URIとして使用できる文字だけで名前を付けているなら何の問題もありません。"[baz]" なんて名前を付けて、"[" や "]" が使えない文字だからといって、
としてもうまくいきません。RFCでは、%XXエンコーディングが使えるようなことが書いてあるのですが、ユーザエージェント側に問題があるのかどうか、どうもうまくありません。仮にこのようにエンコードしての表現が正しいとしても、日本語などの名前を付けようと思ったら、とても悲惨なことになります。"はじめに" という名前をJISでエンコードすると
"%" は、RFC2396では特に例外扱いされていませんが、RFC1738では、アンカー名に使うのは安全でないとされています。
HTML4.01(J)では、アンカー名はASCII文字でなければならないと書いてあります。XHTML1.0(J)では、NAME属性ではなくてID属性でアンカー名を指定するよう薦められており、XHTML1.1では、NAME属性での指定は廃止されました。
<A> のアンカー名 `XXXX` は NN行目にもありました。大文字小文字は区別されない可能性があります。 *3*
HTML4.01(J)では、アンカー名は大文字小文字の一致性を要求するものの、次のような例を不正だとしています。
ここではID属性については触れていません。ID属性の大文字小文字は、要素名や属性名などが区別されないのと同じ理由で区別されません(SGML宣言(J)の NAMECASE GENERAL YES)。NAME属性の値自身は区別されるので、これらは別々のアンカーとして正当なのですが、NAME属性をやめてID属性にしようという思惑から、あえて指摘しているのだと思われます。
HTML4.01(J)では、<A name>で指定するアンカー名と、いろいろなタグのID属性の値は重複してはいけないことになっています。
のようなのが対応してもいいのです。しかし、古いWWWブラウザの実装ではこのような対応はあまり実現できていないようです。
XHTML1.0(J)ではNAME属性でなくてID属性を使うように薦められており、XHTML1.1ではそのようなNAME属性は廃止されています。
のように、同一タグ中でのNAME属性とID属性の値は同じでなければならないとされています。HTML4.0以上以外では警告されません。XHTML1.1では、このようなNAME属性は廃止されています。
XHTML1.0(J)(Appendix C.8)では過渡的な措置として、どちらでもうまくいくように、両方を指定しておくように薦めています。ただし、同じ値を書かなければなりません。過渡的なものなので、XHTML1.1ではそのようなNAME属性は廃止されています。
これは、もともとSGML規格から導出されることなので、ISO-HTMLに限らずHTML4にも言えますが、ISO-HTMLではそのことが明記されているため、ID属性値に小文字を使っただけで警告されます。
SGML宣言の「NAMECASE GENERAL YES」は、単に大文字小文字を同一視せよという意味ではなく、小文字を大文字に変換してから解釈せよという規定です。これは、ID属性値にも適用されるため、HTML4では
また、小文字の ID属性値に対して HREFでリンクされているときも警告されます。ここで注意しなければならないのは、
としなければならないということです。しかし、実際にこのようなSGML的に正しい挙動をするWWWブラウザがどの程度存在するのか、わたしは知りません。たいていは、小文字のフラグメントIDで動作するものと思われます。これは、利用者からは何の違和感もありません。
XHTMLでは、大文字小文字が区別されるのでこのような問題は発生しませんが、XHTMLからHTML内のIDを参照する場合は、そのID値は大文字に変換されるため、大文字で参照する必要があります。
と書いたとき、このアンカーはそのHTML中に存在しなければならないのですが、これが見つからないときに警告されます。名前は大文字小文字が区別されるので注意してください。
指定されているアンカー名が同一のHTML中で参照されていないからといって、それが誤りとはいえません。ただ名前を付けているだけかも知れませんし、別のHTMLから参照されているかも知れないからです。しかし、名前の大文字小文字を間違っていたり、スペルミスなどがないとはいえません。この警告は減点されません。
なんて書くのはちょっと、ということなんですが、RFC1808によると、URIが空の場合は <BASE> で指定されているURIと同じとみなすように書かれています。<BASE> がないときは自分自身と同じなので、そのとき
とした場合は、自分自身にリンクしていることになるのですが、Mozillaなどではそのような効果を期待することはできないようです。それどころか、JavaScriptとの組み合わせで、
URIに空白を含めることは禁止されていませんが、安全ではありません。URI中では空白は %20 として表現します。
URIではディレクトリ階層を示す区切りは "/" です。Windowsなどの "\" は "/" に置き換えましょう。
RFC2396でも、チルダは異なる文字(字形)として入力されることが多いのにもかかわらず、みんなが使うもんだからしょうがなく使えるようにしたことが窺がえます。実際、Shift_JISには半角のチルダは含まれておらず、上線(￣)となっています。
一般の URI (Uniform Resource Identifier) は、RFC2396で規定されています。ASCII コード 20〜7E 以外の文字に対しては、別の警告が出ます。しかし、ASCII文字の中にも使用を除外されている文字がこのRFCに示されています。以下の文字が、除外されています。これらのうち、空白と "\" は別の警告が出ますし、http: スキームのときは "#" はアンカー名の区切りに解釈されます。
これらは、ASCIIコードを、右に示してある % に続く 2桁の 16進数(大文字でも小文字でも同じ)で表現します。
プロバイダ指定のCGIの中には "|" をそのまま書くように指定してあるものもあります。この場合、これを %7C にして動作しないのは、そのCGIが正しい仕様を守っていないからなので、諦めてください。
この有名なアクセスカウンタは、区切りには "|" か "&" を指定できるので、"&" を指定した方がいいでしょう。このとき、HTML中では "&amp;" と書きます (これについては不明な実体参照を参照のこと)。
なお、このCGIの仕様書のキーワード一覧の degrees のところに、MSIEでは &degrees が度文字に解釈されてしまって、これはMSIEのバグだ、と書かれていますが、これはまったくの濡れ衣です。実体参照として &deg; がMSIEに限らずHTML4.01などで定義されていて、これを解釈するWWWブラウザなら度文字が表示されるかも知れないからです(細かいことを言えば、; がないので実体の終わりがわからず、適当に評価されるかも知れないということ)。&amp;degrees と書かない方が悪いのです。さらに具合の悪いことに、degrees は危ないけど代替の angle なら安全だ、などと書かれていますが、&ang; という実体参照も定義されているので、ちっとも安全ではありません。ついでに、&image;、&ne; という実体参照もキーワードと競合します。いずれにしても、パラメタ区切りを "&" のまま書くからいけないので、"&amp;" と書けばどんな場合も安全です。
のようにします。&image のように、CGI呼び出し中の & に続くパラメタが、たまたま定義されている実体参照と同じだった場合にもこの警告が出ることがあります。CGI呼び出し中のパラメタ区切りは &amp; と書くようにしましょう。
&#255; のような文字参照も同様です。このとき、含まれる # はアンカー名との区切り文字とはみなされません。
URIに使用できる文字は、ASCII コード 20〜7E の文字だけです。漢字やカタカナなどは使用できません。
URIに指定できるスキーム名は、英小文字、数字、プラス "+"、ピリオド "."、ハイフン "-" から成る、とRFC2396に書いてあります。英大文字についてはそれを小文字とみなしてもよいとも書いてあります。この警告は、これらに違反したときに出ます。
URIに指定するスキーム名に使える文字には、本当は英大文字は含まれていませんが、RFC2396では、大文字を小文字とみなすような融通を利かしてもよいと書いてあります。
URIに指定できるスキームに何があるのかをすべて把握しているわけではありません。いくつかのRFCにあるものなどを拾ってありますが、これらに含まれないスキーム名のときこの警告が出ます。もし、正しいのに警告されるときは k16@chiba.email.ne.jp までお知らせください。でも、多くはスペルミスです。
また、セキュリティサーバのための https: などはRFCにはありませんし(たぶん)、HTMLで使って有意かどうかは別にして、他のRFCにもさまざまなスキームが定義されていますが、ここでの紹介は割愛します。
といったスキームも使用できます。これらのMozilla特有のスキームについては、Netscape Tips&Tricks などを見てください。
インタネット上に公開するHTML中のURIに、file: などのローカルファイルを指すスキームを指定しても、そのファイルを参照することはできません。
URIに"javascript"を使うのは、利用者がスクリプトを使わない環境のときなどのことを考えて、使用を慎むように、アクセス指針技術文書4.12.1(J)に書かれています。しかし、実際には必ずしも制限される必要のない javascript スキームも少なからず存在します。例えば、javascript が動作すれば恩恵を被るものの、動作しなくてもなんら支障のないような場合などです。この警告は減点されません。
URIの格好はRFC2396で決められていますが、これは総括的な一般URIの構文を規定しているだけで、個々のスキームごとの構文を規定しているわけではありません。ここでは、RFC1738などで決められている次のスキームについて個別のチェックを行ないます。このチェックに違反するとこの警告が出ます。
ただし、上記構文はかなり端折ってあり、正確ではありません。本当はそれぞれもっといろいろな書き方があります。正確な構文等を知りたいときは以下を参照してください。ただし、Another HTML-lint ではRFC1738以外が必ずしも反映されているわけではありません。また、RFC2396には、これらの修正情報があります。
個々のスキームごとに使用できる文字が微妙に異なっていますが、URIで表記するときにRFC2396で禁じられている文字を、直接書いたり実体参照などを用いて表現したりすることはできません。このような文字は、すべて %3C のように表現しなければなりません。
相対指定のURIに http: などのスキーム名を付けることはできません。http: は付けないようにします。
ホスト名は英数字とハイフンから成る文字列(ハイフンは先頭や末尾には来ません)をピリオドで繋げたものです。下線などは使えないことになっています。
ホスト名のピリオドで区切られた各ドメインラベルは、英数字で始まって英数字で終わらなければなりません。ハイフンで終わったりしてはいけません。
http: にユーザIDやパスワードを含めることはできないことになっています。しかし、一部のユーザエージェントはこれを受け付けています。安全のためには、URI中に素のパスワードなどは書かないようにしましょう。ftp: などには構文上含められます。
CGIのパラメタ区切りに | が用いられています。| はURIに使えない文字なので %7C と表記しなければならないのですが、残念ながら、そうすると動作しないCGIが多数存在します。Muquit氏のアクセスカウンタ (Count.cgi) に関してURIに使えない文字の解説を見てください。
スキーム名の後ろに空白が含まれています。URIの最後とかに余計な空白が入っているときも同様です。空白を%20と書いているときはこの限りではありません。
Windowsなどのローカルのファイル名をそのままURIとして利用することはほとんどの場合できません。ローカルホストをアクセスするためには、ホスト名を localhost とするか空にする必要があります。また、WindowsやDOSのディレクトリ区切り \ は使えないので / に置き換えます。Macintoshのディレクトリ区切り : も / に置き換えます。
WindowsやDOSのドライブ区切りの : を | に置き換えることもあるようです(これの出典はどこですか? k16@chiba.email.ne.jp までお教えください)。しかし | はURIに使えない文字なので %7C と表記します。
mailto: URI は、RFC1738では、単一の宛先だけを含むように書かれていましたが、RFC2368によって、(RFC822ではphraseと呼ばれる)宛名を含めたり、複数の宛先を列挙したりできるように拡張されました。これをHTML中で記述するためには注意が必要です。URI中に書けない文字はすべて%20のように書かなければなりません。
などと、日本語などを入れようとしたら、まずURIとして合法的な表現をするのは人間わざではほぼ不可能だと思っていいでしょう。
mailto: は、他の(http:などの)スキームと異なり、直ちにこのURIによってメールが送信されたりすることはありません。WWWブラウザがこのURIの情報を解釈してメーラに渡し、メーラを利用者が操作して(本文などを書いてから)メールを送信することになります。このため、mailto: URIの書式にはかなり自由度のある実装がされていると思われます。
これは nntp: の構文です。多くのユーザエージェントはこれを news: として受け入れているようです。現在のRFC的には news: として正しい構文とはいえませんが、許容される方向にあるようです。
ドメイン名が . で始まったり、IPアドレスになったりすることはありません。RFC1738の構文ではIPアドレスになり得ますが、RFC1036で「RFC822に従がう」とありRFC822ではIPアドレスは使用できません。(ちょっと自信なし :-)
一部のニュースリーダは、このようなメッセージID (の < > を除いた部分) を送出することがあるようです。これは記事を投稿する側の問題なので、記事を参照したり引用したりする側ではどうしようもありません。
本来の目的とは無関係に、mailto: などの後ろに文章を書くという裏技(?)が存在するようです。これは、Mozillaなどでマウスを持って行くとステータスラインにその文章が表示されるという効果を狙ったものだと思われます。
URIで指定できるスキームには、http、ftp、mailto などいろいろありますが、http/https スキームについてだけ調べています。http スキームのURIは、
と書いてしまうと、fake というファイルを探しに行ってみたら、実はそれはディレクトリだった、ということで、改めて index.html なりを探しに行くので、むだが多く、好ましくありません。だから、ディレクトリを示すURIには "/" を付けなければなりません。しかし、実際にそのURIが存在するかどうかは、(指定されたとき以外は)Another HTML-lintでは調べていないので、このような場合の警告を出すことができません。ここでは
というような場合にだけ警告が出ます。アカウント名のプレフィクスは、指定で ~ 以外にもなるんだけど、まあ、多くは ~ だろうということです。
URIが存在するかどうかチェックしているときには、実際に "/" が必要かどうかがチェックされることがあります。現在はURI取得の方法にLWPを使った環境でのみ可能です。
というのは誤りではありません。このホスト名の指定だけの場合は "/" を省略してもいいことになっています(RFC1738、RFC1808)。
// で始まるURIは、正しいURIです。しかし、これはWWWブラウザによっては正しく評価されないかも知れません。
というURIが指定されている場合、"/" のある方とない方とどちらかが間違いなのが明白です。この警告はこのようなとき出ます。http/https スキームについてだけ調べています。
なーんて、浅知恵で考えていましたが、実際には "/" のありなしでまったく異なるリソースを指すことが可能です。例えば、
とは言っても、そのような設定をされているサーバがそんなに多いとも思えないので、この警告自身は残しておきますが、減点されません。
などが混在しているときに警告されます。WWWブラウザは、これらが同じリソースかどうかを判断できないので、別々にキャッシュしてしまい、効率的でありません。http/https スキームについてだけ調べています。
は同じリソースを指すとみなしています。こんなことはしないと思っていたら、(同じリソースを指すという前提で)存外にすることがあるようです。
<BASE> でHREF属性を指定するときは、それより前に相対URIを用いて外部との関連付けを行なってはなりません。
HTML4.01(J)では、一切の参照を制限しています。HTMLかどうかなど、リソースの種類についての限定は行なっていないことに注意してください。しかし一方で、<BASE> は相対URIに対してのみ効果のあることも書かれています。Another HTML-lint では、<BASE> 以前に出現する相対URIについてのみ警告します。
のようなのもだめです。<BASE> は、なるべく <HEAD> 要素の最初の方に書くようにしましょう。
HTMLは </HTML> が現れたらおしまいです。WWWブラウザによっては </HTML> の後も表示しますが、そんなのを期待してはいけません。
NTT DoCoMo の iモード用のHTML文書は2Kバイト(2.0では5Kバイト)以内に、J-SkyWeb用のHTML文書は6Kバイト以内に、それぞれ収めなければなりません。このバイトサイズには、ページ中で使用されているイメージファイルのサイズも含まれるのですが、通常はそこまでは加算してのチェックはされません。URIが存在するかどうかチェックしているときには加算されます。
NTT DoCoMo の iモード用のHTML文書に利用できるイメージはGIFのみです。さらに iモード 1.0 では２階調GIFのみの対応なのですが、調べたGIFが２階調かどうかはチェックされません。
変な決まりですが、特許出願用文書の先頭は <HTML> でなければなりません。覚え書きを見てください。
特許出願用文書は Shift JIS で書かなければならない決まりです。覚え書きを見てください。また、NTT DoCoMo の iモード 用のときも Shift JIS で書かなければなりません。覚え書きを見てください。
特許出願用HTMLに使える文字については、くどくどいろいろ細かい決まりがあるのですが、とりあえず、利用者使用禁止となっている文字だけチェックしています。また、使える文字として半角カタカナや、丸付き数字の一部などが追加されています。覚え書きを見てください。

 

戻る

Copyright ©2005 レーシック・美容整形類義語辞典