あまりエラーが多いときは、チェックを打ち切るようにしています。打ち切られた行以降の文書には、もしかしたら重要なエラーが含まれているかも知れませんが、チェックされません。同じようなエラーばかり出ているときは、そのエラーをチェックしないようにしてみてから、もう一度チェックしてみるといいでしょう。
もしも、同じ行の同じエラーがずっと繰り返されている場合は、プログラムの不具合だと思われますので、是非 k16@chiba.email.ne.jp までお知らせください。
出力されるエラーは、だいたい次のように分類されます。
各エラーが、それぞれどういう質のものなのかを * で示してあります。
あまりエラーが多いときは、チェックを打ち切るようにしています。打ち切られた行以降の文書には、もしかしたら重要なエラーが含まれているかも知れませんが、チェックされません。同じようなエラーばかり出ているときは、そのエラーをチェックしないようにしてみてから、もう一度チェックしてみるといいでしょう。
もしも、同じ行の同じエラーがずっと繰り返されている場合は、プログラムの不具合だと思われますので、是非 k16@chiba.email.ne.jp までお知らせください。
<TAG> の ATTR 属性の URI `XXXX` はインタネット上に存在しないかアクセスできません。 **
指定されているURIが実際に存在するのかチェックしますが、処理の迅速化のためにタイムアウトの時間はかなり短く設定されています(変更可)。それでも、サーバの反応が遅いリンクが多い場合は時間がかかるでしょう。http: スキームのみチェックしています。ただし、正しくないURIのときはチェックしません。
メッセージの後に数字が付いている場合、それは、HTTPリクエストの結果のコードです。このコードは大きく分けて次のように分類されています。
| 100番台 | 通知 | |
| 200番台 | 成功 | |
| 300番台 | 移転 | |
| 400番台 | クライアントエラー | |
| 500番台 | サーバエラー |
これらのうち、このチェックで返ってくる可能性のあるコードでエラーとなるのは 400番以降のときです。しかし、確実にリソースが存在しないかアクセスできないのは次の場合くらいです。
| 403 | アクセス権がない | |
| 404 | ファイルが存在しない | |
| 410 | サーバから削除された |
認証が必要なもの(401)などはそのリソースが存在することは明らかですし、サーバエラーのときは存在するのかしないのかは不明です。Another HTML-lint ではこのようなリソースの文法チェックをすることはできません。
LWPでなくhttpreq.plを使っているとき、1桁のコードが返ることがあります。それは、HTTPリクエスト以前にエラーが発生したときで、次のような意味です。
| 2 | IPが得られない | |
| 3 | ホストに接続できない | |
| 4 | タイムアウト |
LWPでは、DNSが引けずにIPが得られない場合、500番のコードを返します。
HTTPのステータスコードに関して詳しくは、RFC1945、RFC2068、RFC2616などを見てください。
JavaScriptなどを利用して <BASE> を動的に変更していたりする場合は正しくチェックできません。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
一部のISPでは、受け付けるHTTPリクエストを制限していることがあります。このとき、「GETリクエストでチェック」オプションを指定していない場合は、すべてのURLに対して存在しないなどとエラーになりますのでご注意ください。
HTMLには、いろいろな仕様(ヴァージョン)があります。DOCTYPE宣言は、文書がHTMLであり、さらにどの仕様のHTMLで書かれているのかを明示するものです。DOCTYPE宣言がなくても、たいていのWWWブラウザは(自分の都合のいいように)HTMLを表示してくれますし、まじめにDOCTYPEによってHTMLの評価を変えてくれるWWWブラウザが現存するのかどうか知りません。しかし、DOCTYPE宣言は書くようにしましょう。とはいえ、MSIEやMozillaなどには対応するDOCTYPEがないので、にっちもさっちもいきません。
DOCTYPE宣言は、<!DOCTYPE ～> という書き方をします。"!" を書き忘れていないかチェックしましょう。
HTMLの場合のDOCTYPE宣言は、<!DOCTYPE HTML ～> となります。実は、この中にあるHTMLという記述が、HTML全体をくくる <HTML>～</HTML> を表わしているのですが、Another HTML-lint ではHTML以外は想定していません。
DOCTYPE宣言の前に何か制御文字が含まれています。 **
DOCTYPE宣言の前に、何か制御文字が含まれています。これは、JISのエスケープコードなど、不可視かも知れません。バイナリダンプなどでの調査が必要かも知れません。
現在 Another HTML-lint がサポートしているDOCTYPEは以下のとおりです。なお、以下「DOCTYPEはありません」と書いてあるのは、公開識別子がないという意味です。
DOCTYPE宣言の意味については、文書タイプ宣言の意味などを見てください。特に、宣言末の "EN" というのは、宣言されているDTDが英語で書かれているという意味で、そのHTML文書がどうこういう意味ではありません。勝手に "JA" などに書き換えてはいけません。
また、HTML4.0がHTML3.2の上位互換などということはありません。ほとんどのHTMLにはこのような互換性はありません。
XHTMLでは、DOCTYPE宣言内にシステム識別子が必要です。
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN">
<!DOCTYPE HTMLPLUS SYSTEM "HTMLPLUS.DTD">
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">
<!DOCTYPE HTML SYSTEM "html40-mobile.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<!DOCTYPE html PUBLIC "-//OPENWAVE//DTD XHTML Mobile 1.0//EN" "http://www.openwave.com/DTD/xhtml-mobile10.dtd">
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HyperText Markup Language//EN"><!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HTML//EN">
<!DOCTYPE Pre-HTML PUBLIC "ISO/IEC 15445:2000//DTD HyperText Markup Language//EN"><!DOCTYPE Pre-HTML PUBLIC "ISO/IEC 15445:2000//DTD HTML//EN">
<!DOCTYPE HTML PUBLIC "-//Microsoft//DTD Internet Explorer 3.0 HTML//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD Compact HTML 1.0 Draft//EN">
<!DOCTYPE html PUBLIC "-//i-mode group (ja)//DTD XHTML i-XHTML(Locale/Ver.=ja/1.0) 1.0//EN" "i-xhtml_4ja_10.dtd">
<!DOCTYPE html PUBLIC "-//i-mode group (ja)//DTD XHTML i-XHTML(Locale/Ver.=ja/1.1) 1.0//EN" "i-xhtml_4ja_10.dtd">
もしも、あなたが使用しているDOCTYPEがここになくて、そのDTDが存在している場合は、k16@chiba.email.ne.jp までお知らせくだされば、追加できるかも知れません。
以下は、よくある間違った宣言です。
<!DOCTYPE HTML PUBLIC "HTML 3.0">
<!DOCTYPE HTML PUBLIC "HTML 3.2">
<!DOCTYPE HTML PUBLIC "-//IBM//DTD HPB HTML//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
最初の３つは IBM HomePage Builder が、最後のは Internet Explorer 4.0 が生成するようです。
改造者追記：HTML Living Standardの<!DOCTYPE html>には、ほとんど意味はありません。ただし、これを記述しないとIE等のブラウザで標準モードでレンタリングされないなどの問題が生じます。また、これを記述しないでXML構文を用いると、XHTML1.0または1.1として解釈される可能性もなきにしもあらずかもしれません。
DOCTYPE宣言に指定されている公開識別子の大文字小文字が正しくありません。 *6*
DOCTYPE宣言中の "-//W3C//DTD HTML 4.01 Transitional//EN" などの公開識別子の大文字小文字は区別されます。
XXXX は Another HTML-lint ではサポートされていない DOCTYPE宣言です。
既知のいくつかの未サポートのDOCTYPE宣言に対して警告されます。
HTMLXXXX はすでに廃棄されたHTMLです。使わないようにしましょう。 *3*
DOCTYPEに宣言されているHTML2.0やHTML3.0などは、すでに破棄されてしまった仕様です。使わないようにしましょう。
HTMLXXX はあまり薦められないHTMLです。HTMLYYY を使いましょう。 *3*
この警告は減点されません。
DOCTYPEに宣言されているHTML4.0は、使うことが薦められていません。改訂版のHTML4.01を使いましょう。
改造者追記：HTML3.2, HTML4.0, HTML4.01, XHTML1.0, XTHML1.1, XHTML Basicに対しては、W3Cは、最新版を使うよう推奨してます。
指定されている XXXX は DOCTYPE宣言と一致しません。DOCTYPE宣言を無視します。
指定されたDOCTYPEが正しいかどうか、特にスペルミスがないかチェックしましょう。
DOCTYPE宣言は文書の先頭でなければなりません。 *5*
DOCTYPE宣言は、コメントやXML宣言を除く文書の先頭に書かなければなりません。つまり、<HTML> より前に書かなければなりません。
DOCTYPE宣言中の `HTML` は小文字で書かなければなりません。 *5*
DOCTYPE宣言 <!DOCTYPE HTML ～> にある HTML というのは、HTML文書が <HTML>～</HTML> で囲まれていることを示すものです。XML(J)では、要素名や属性名の大文字小文字が区別されます。大文字の <HTML> と小文字の <html> とは別物に解釈されます。すべての要素名が小文字のXHTML1(J)では、小文字の html でDOCTYPE宣言しなければなりません。
DOCTYPE宣言中の `!doctype` や `public` は大文字で書かなければなりません。 *5*
XHTMLでは、DOCTYPE宣言は大文字でしなければなりません。
システム識別子は、DOCTYPE宣言中にあるDTDの所在を示す情報で、次のようなもの。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTMLでは、システム識別子を書かなければなりません。
DOCTYPE宣言に指定されているシステム識別子が正しくありません。 *6*
DOCTYPE宣言中に指定されているシステム識別子が正しくありません。公開識別子に対応するシステム識別子は決まっています。
DOCTYPE宣言に指定されているシステム識別子の大文字小文字が正しくありません。 *5*
DOCTYPE宣言中に指定されているシステム識別子の大文字小文字が一致していません。
SGML宣言や DTD宣言などと思われる <!XXXX ～> は無視します。
<!SGML ～> とか <!ELEMENT ～> とかいう宣言は、DOCTYPEを除いてすべて無視します。実際に存在する宣言かどうかはチェックしないので、でたらめな <!USO800 ～> とかでも黙って無視されます。実際には次のような宣言が存在します。
<!SGML ～> |
<!DOCTYPE ～> |
<!ELEMENT ～> |
<!ATTLIST ～> |
<!ENTITY ～> |
<!NOTATION ～> |
<!SHORTREF ～> |
<!USEMAP ～> |
もしも、タグをコメントアウトするつもりで "<!IMG ～>" などと書いているなら、それは "<!--IMG ～-->" と書かなければなりません。
マーク区間 <![XXXX[ ～ ]]> は、多くのブラウザは理解できません。 **
マーク区間というのは、<![CDATA[ ～ ]]> のようにしてSGML文書の一部分にいろいろな性格付けをしたりするものですが、多くのWWWブラウザはこの書式を理解できませんし、Another HTML-lint もきちんとは解釈できません。HTML4.01(J)にもあまり使わない方がいいと言及があります。
マーク区間には次のようなものがありますが、いちいちスペルチェックはしていません。
<![CDATA[ ～ ]]> |
<![RCDATA[ ～ ]]> |
<![IGNORE[ ～ ]]> |
<![INCLUDE[ ～ ]]> |
<![TEMP[ ～ ]]> |
XHTML1(J)では、<SCRIPT> などの要素がCDATAではなく#PCDATAになっているので、旧来のように記述するためには、
<script> <![CDATA[ ... unescaped script content ... ]]> </script>
としなければならなくなりました。Another HTML-lint では、CDATAマーク区間のみ、HTML4以上に限って解釈しています。他のマーク区間は、入れ子の関係が許されたりいろいろ複雑なので、かなり大雑把にしか扱っていませんし、意味を斟酌してもいません。
また、構文上 <![ CDATA [ のように空白を含められるのですが、手抜き実装のため、複数行に渡っての記述は解釈できません。閉じる場合も同様です。
この警告は減点されません。
一般のマーク区間中には、次の文字列を記述することはできません。XML(J)。
]]> |
< |
& |
CDATAマーク区間では、次の文字列が書けないことになっています。
]]> |
スクリプトやスタイルシートの記述中にこういう字面を含むようなものをHTML中に埋め込むことはできません。そのようなときは外部にスクリプトやスタイルシートを用意しなければなりません。
ただし、チェックはCDATAマーク区間のみHTML4以上に限って行なっています。実際にこのエラーが出ることはありません。
NN行目のマーク区間 <![XXXX[ が閉じられていません。 *6*
マーク区間が閉じられていません。閉じる場所に関しては Another HTML-lint は無頓着です。
<?xml で始まるXML宣言は、文書の先頭に書かなければなりません。つまり、DOCTYPE宣言よりも前に書かなければなりません。
XHTML では XML宣言をすることが強く求められています。 *3*
XHTML1(J)では、XML宣言をするように強く求められています。例えば次のようなもの。
<?xml version="1.0" encoding="UTF-8"?>
改造者追記：文字コード判定がUTF-8のときは（charset指定ではなく実際に記述されている文字からの判定なので、判定ミスもありうる）、警告対象外とした。XHTMLの仕様ではUTF-8のときはXML宣言は省略可能であるため。
改造者追記：HTML Living StandardのXML構文のときは、警告対象外とした。
一般の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)では、"--" と "--" の間がコメントとみなされ、その組が複数回現れてよく、それらの組と組の間は空白文字だけが書ける、となっています。つまり、次のような書き方は間違いです。
<!-----------> <!-- FOO -- BAR -- BAZ -->
最初の例は、"--" が正しく組になっていませんし、次の例は組と組の間が空白ではありません。以下の例は正しいのです(ただしRFC1866として)。
<!------------> <!-- FOO -- -- QUZ -->
上の例は、ハイフン "-" が 12個で、ちょうどうまく組になるのです。
Another HTML-lint では、このような正確な仕様を調べるのではなく、単純に余計な "--" が現れただけで警告するようにしています。しかし、多くのWWWブラウザでは、このようなコメント中のハイフンの扱いについては、相当寛容です。
HTML4.01(J)では、コメント中に 2個以上連なったハイフンは書かないように、とされています。XML(J)でも禁止です。つまり、上の例はすべて誤りです。
RFC1866(J)では、空のコメント "<!>" は、"--" がゼロ組のコメントとして正しいコメントとされています。でも、書かない方がいいでしょうね。混乱の元です。XML(J)にはこのような表記は存在しません。
このコメントのような記述 `<!->` は正しくありません。 *6*
次のようなのは、そもそもコメントとして正しくありません。こういうのを書いてはいけません。
<!-> <!--> <!--->
<TITLE> 中にはコメントを書かないようにしましょう。 *3*
<TITLE>中には、コメントも含めてテキスト以外は書かないようにとされています。HTML4.01(J)を見てください。
コメント中に `<` や `>` を書くと、いくつかのWWWブラウザを混乱させることがあります。 *
HTMLの一部をまとめて
<!-- <A href="～">なんたら</A> -->
のようにコメントアウトすることはごく普通に行なわれると思いますが、一部のWWWブラウザでは、
<!-- <A href="～">
までをコメントとみなしてしまうものがあるそうです。これは、WWWブラウザが悪いというよりも、古いHTMLでこのような実装がされ得ていたようです。今時のWWWブラウザではこんなことはないようです。この警告は減点されません。
コメントを入れ子にすることはできません。
<!-- <!-- かんたら --> -->
このようなとき、多くのWWWブラウザでは、
<!-- <!-- かんたら -->
までがコメントとみなされて、残りが宙に浮いてしまいます。SGML的には「かんたら」の部分が非コメント部分とみなされてうまくありません。
閉じコメントの `--` と `>` の間には空白を入れないようにしましょう。 *
仕様上は、"<!-- ～ -- >" と書いてもいいことになっています(XML(J)では禁止)。しかし、逆に "<! -- ～ -->" とすることは禁じられています。このときは、< とタグ要素名の間に空白が含まれていると警告されます。
閉じコメントは `--!>` ではなく `-->` です。 *6*
読んで字の如くです。WWWブラウザによっては気を利かせて "--!>" の位置でコメントを閉じてくれますが、そうでない場合は、その後ろの記述がずっと無視されることになります。
また、コメントを "<!- ～ ->" と勘違いしている人もあるようです。
"<!--" が現れたのに "-->" が最後まで現れなかったときの警告です。コメントを入れ子にしたりして、どこか間違えたのでしょう。
タグが "<" で始まったのに ">" が最後まで現れなかったときの警告です。
`<` と `TAG` の間には空白を入れてはいけません。 *6*
タグの開始は、"<TAG" のように続けて書かなければなりません。"< TAG" のように書いてしまうと、タグとして認めてもらえません。もしも、"<" を "<" という文字の意味で書いたのなら、それはそれで "<" と書かなければなりません。これについては、実体参照に関する警告を参照してください。
特許出願用HTMLでは、これが許可されているのですが、あまりにもひどい許容なので、この場合でも警告されます。
予期せぬ `<` が <TAG> 内にあります。閉じられていないタグの可能性があります。 *6*
閉じるのを忘れたタグの後に正しいタグがある場合に出ることが多い警告です。
<A href="～"><IMG src="～" </A>
といった調子です。このとき、</A> の前に ">" が補われます。
もっと本当のことを言えば、実はこれはSGML的には間違っているとは言えません。SGML宣言で SHORTTAG YES のときにはタグの連続で直前のタグの > を省略してもいいことになっているからです。HTMLはどれも SHORTTAG YES です。終了タグだって、それがどの開始タグに対応するか自明な場合は </> としてもいいとか、もっといろいろあるんですが、そこまで正しいSGML的解釈をWWWブラウザに期待できません。HTML4.01(J)などを見てください。
空要素タグ <TAG> は <TAG /> として閉じなければなりません。 *5*
XHTML1(J)では、<br> や <hr> などの空要素タグは、<br /> や <hr /> と書かなければなりません。
実際には、<br></br> と書いてもOKです。終了タグがないときの警告も参照してください。
空要素タグ <TAG> を閉じるときは `/>` に空白を先行させましょう。 *3*
XHTML1(J)では、XMLを解さないユーザエージェントのために、空要素タグを閉じるときは <br /> や <hr /> のように /> の前に空白を先行させるように薦められています (Appendix C.2)。
なぜこれでXMLを解さないユーザエージェントのためになるのかというと次のような理由によるようです。
/ は、要素名とはなり得ない文字なのですが、<br/> という記述に対して古いユーザエージェントは br/ を要素名とみなし、未知のタグということで無視してしまうようです。これを <br /> とした場合は、既知の br なのでちゃんと改行される。ということのようです。
XML(J)ではこの空白はあってもなくても構いません。メディアタイプが application/xhtml+xml である場合は警告されません。
空要素タグ <TAG> の要素には空白さえも含めることはできません。 *6*
XMLの Content of Elements(J)では、空要素タグは、<tag></tag> のように開始タグと終了タグをくっつけて書かなければならないとされてます。つまり、空白も含めることはできません。
空要素タグは <TAG /> と書くようにしましょう。 *3*
XHTMLのガイドライン C.3(J)には、後方互換性のために、空要素タグは、<tag></tag> ではなくて、<tag /> と書くようにとされています。
メディアタイプが application/xhtml+xml である場合は警告されません。
非空要素タグ <TAG> を `/>` で閉じることはできません。 *5*
XHTML1(J)では、<p> などの非空要素タグに対して、<p></p> を <p /> と表記してはならないことになっています (Appendix C.3)。
メディアタイプが application/xhtml+xml である場合は警告されません。
<TAGA> を NN行目の <TAGB> 内に書くことはできません。 *6*
タグには開始タグ <TAG> と終了タグ </TAG> の対で用いられるものが多くあります。このタグの要素として、何が書けて何が書けないかは明確に決められています。
HTML4.01 Strict(J)では、ブロックレベル要素とインライン要素の区別が厳格になっているので、「あれ? どうしてこれがエラーなの」と疑問に思うものが多いかも知れません。例えば、<BODY> や <FORM> 内に直接インライン要素を書くことができなくなっています。<A> や <INPUT> などはインライン要素なので、次のようなのは HTML4.01 Strict では誤りとなります。
<BODY> <A>リンク</A> ← <A> は <BODY> に書けないと警告 <FORM> <INPUT>何故? ← <INPUT> は <FORM> に書けないと警告 </FORM> </BODY>
これは、例えば次のようにします。
<BODY> <P> <A>リンク</A> </P> <FORM> <P> <INPUT>何故? </P> </FORM> </BODY>
DOCTYPEの意味をわからずに、「とにかくHTML4.0のやつ」と不用意に宣言している人はこの警告を大量に食らうことになります。そういう人は、とりあえずHTML4.01 Transitionalな宣言を付けましょう。そしてその意味を勉強してください。
HTML4.0以外でも、気付きにくい有名なよくある(ほんとによくあるのか?)間違いとして、
<A href="～"><H3>ぽよよん</H3></A>
というのがあります。HTML3.2やHTML4.0などでは、<A>～</A> 内には <H3> などは書くことができません(しかし、なんとHTML2.0では書けるので間違いではないんだけど、、、)。正しくは
<H3><A href="～">ぽよよん</A></H3>
とします。しかしWWWブラウザは寛容なので、たいていどちらもそれなりに表示します。
また、</A> を書いていない場合にもこの警告がよく出ます。
<A href="yama.html">おじいさんはやまにしばかり <A href="kawa.html">おばあさんはかわにせんたく
なんていう書き方をしているときです。</A> は省略できないタグなので、<A>～</A> の中に <A> が書かれていると解釈されますが、<A>～</A> の中に <A> は書けません。
<UL> や <OL> を入れ子にしてこの警告を受け、「<UL> って入れ子にできないんだっけ」と疑問に思われる方もいるようです。
<UL> <UL>～</UL> </UL>
これは正しくありません。<UL> を入れ子にするには、
<UL> <LI><UL>～</UL></LI> </UL>
という風にしなくちゃならない。後ろの </LI> は省略可。
<TABLE> で <TR> を書かなかったために、<TBODY> 内に <TD> が書けないと言われることもHTML4.01ではよくあります。
<TABLE> <TD>～</TD> </TABLE>
「<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> は、それらがどの要素中で使用されるかによって、書ける要素が違います。つまり、インライン要素として記述した場合はブロックレベル要素は書けません。
<P> <INS><DIV>…これはブロックレベル要素…</DIV></INS> </P>
この例は正しくありません。<P> の中に <DIV> は書けないからです。
改造者追記：HTML Living Standardではいくつかの要素がトランスペアレント要素となっており、親子関係については親要素の制約がそのまま承継されます。そのため、「えっ、なぜこれが書けないの？」と思うようなこともあるかもしれませんが、よく確認してください。例）HTML Living StandardではA要素はなんでも囲めるようになったかに思われがちですが、<EM><A><H1>～</H1></A></EM>なんてことをしてると、A要素の中にH1要素は書けないと警告されます（A要素はトランスペアレントなので、親のEM要素の制約を継承している。EM要素の中にH1要素は書けない）。
改造者追記：HTML Living Standardで、math要素内・svg要素内のimage要素がうまく扱えないため、またsvg要素内のa要素・title要素・script要素・style要素も同様のため、この警告が出ることがあります。Nu Html Checkerでのチェックをお薦めします。
改造者追記：HTML Living Standardで、itemprop属性付きのmeta要素とlink要素は、Flow contentでありPhrasing contentでもありますが、この改造版ではPhrasing contentとしては扱ってない（＊）ので、そのせいでこのエラーが出ることがあります。＊RDFa+HTMLの場合と扱いをあわせたのと、内容モデルとしてPhrasing contentしか許していない要素のほとんどは、テキストになんらかの意味づけをするものであり、その要素の内容としてテキストとして表示されないmeta要素やlink要素を配置するのはほとんど無意味と考えられるため。
改造者追記：HTML Living Standardで、noscript要素内にscript要素が書ける場合があるのですが、この改造版では一律に書けないものとしてます（実際の用例としては想定しがたいですし）。
<TAGA> を NN行目の <TAGB>～</TAGB> 内に書くことはあまり薦められません。 *3*
とりあえず書いても大丈夫ですが、薦められていません。将来的に書けなくなる可能性があります。この警告は減点されません。
<TAGA> を <TAGB>～</TAGB> の外に書くことはできません。 *3*
タグによっては、ある条件で特定のタグの要素内にしか書けないものがあります。多くは内部に書けないと警告されますが、DTDで規定できない場合はこの警告が出ます。
<IMG ISMAP> は、<A HREF>～</A> の外には書けません。これは、HTML2.0 や ISO/IEC 1544 などに書かれています。
<TAGA> は <TAGB>～</TAGB> 内に1度しか書けません。NN行目にもありました。 *6*
タグによっては何度も書けないものがあります。<BODY> や <TITLE> や <CAPTION> などいろいろあります。これらは、HTML中で一度だけ書けるという意味ではなく、<BODY> ならばそれを書くことができる <HTML>～</HTML> 内で一度という意味です。<HTML> は一度しか書けないので <BODY> も一度しか書けないことになりますが、<CAPTION> は <TABLE>～</TABLE> 内で一度です。<TABLE> は何度でも書けるので、<CAPTION> 自体はHTML中に何度も現れることがあります。
<TAGA> は NN行目の <TAGB> と同時に <TAGC>～</TAGC> 内に書くことはできません。 *6*
例えば、HTML4.01(J)では、<BODY> と <FRAMESET> は、どちらも <HTML>～</HTML> 内に書くタグですが、両方を書くことはできません。これは、このような制限のあるタグに対する警告です。
<TAGA> は </TAGB> の直後に続かなければなりません。 *6*
決まった順序で書かなければならないタグがいくつかあります。<HTML>～</HTML> 内では、<HEAD> の次に <BODY> という順序でなければなりませんし、<TABLE>～</TABLE> 内では、<CAPTION> を <TR> などの後に書くことはできません。
<DD> は </DT> の直後に続かなければなりません。 *3*
<DL> 要素内には <DT> タグと <DD> タグが書けるのですが、ひとつの <DT> に対して、いくつも <DD> を書くようなやり方は、RFC1866(J)では推奨されていません。
<DL> <DT>見出し１ <DD>～ <DT>見出し２ <DD>～
は、もちろんいいのですが、
<DL> <DT>見出し１ <DD>～ <DD>～
は、だめということです。次のように <DD> がないのはいいようです。
<DL> <DT>見出し１ <DT>見出し２ <DD>～
<DD> を複数続けたいような場合は、例えば <BR> を使えばいいでしょう。
これに関して、HTML+のDTDでは次のように定義されています。これは、DLの内容はひとつ以上の連続するDTにひとつのDDが続いた組がひとつ以上、と読みます。つまり、HTML+ではDDを続けることは禁止されています。
<!ELEMENT DL - - (DT+,DD)+>
RFC1866(J)以降では次のように定義されています。これは、DLの内容はDTまたはDDがひとつ以上、と読みます。順序の規定は含まれていません。
<!ELEMENT DL - - (DT|DD)+>
HTML+が 1993/11、RFC1866 が 1995/11 なので、RFC1866の記述はHTML+の名残、あるいは修正漏れの可能性が大です。
HTML4.01(J)には、<DD> を連続させた例が載っています。ということは、HTML4.0では、DTDどおりに、こう書いても問題なしとなったんでしょう。HTML4.0以上では <DD> の連続に対してこの警告は出ません。
必ず書かなければならない要素があります。例えば、<HEAD>～</HEAD> 内に <TITLE> は必要です。
改造者追記：HTML Living Standardでは<TITLE>は例外的に省略可能な場合がありますが、必須扱いで判定してます。
改造者追記：HTML Living Standardでは、TABLE要素の直下にTR要素を配置した場合も、TBODY要素の配置を促すためにこの警告が出ます（減点数は下げてある）。TBODY要素の配置は必須ではありませんが、歴史的経緯から、TBODY要素なしでTR要素を配置した場合、XML構文と解釈されたときとHTML構文と解釈されたときで、異なるDOMが構築されるため、それを防止する方が望ましいとする考え方があるからです。TBODY要素なしでTR要素を配置した場合、HTML構文での解釈では「TABLE要素 ＞ タグが省略されたTBODY要素 ＞ TR要素」という親子関係でDOMが構築され、XML構文での解釈では（タグの省略がそもそも許されないため）「TABLE要素 ＞ TR要素」という親子関係でDOMが構築されます。
ある種のタグは、要素が空であるのが好ましくないことがあります。例えば、
<ADDRESS></ADDRESS>
などというのでは、何のための <ADDRESS> なのかわかりません。特に、<P> を <BR> の代わりに改行の意味で使っていたりすると、</P> が省略されているとみなされて、さらにこの警告が出ることが多くなります。<P> は段落のためのタグであり、改行のためにあるのではありません。
また、
<A name="anchor"></A>
としたのでは、Lynxなど一部のWWWブラウザではそこに飛べなくなってしまいます。文法的には間違っていないし、同じ場所に複数の名前を付けたりするのはよくやることだと思いますし、そもそもアンカーはその一点に指定するのであって、ある範囲に指定するのではありません。Lynxなどが飛べないのは、不具合に近いと思います。なお、最近のLynx(2.8.1)ではそのようなことはないようです。
改造者追記：HTML Living Standardでは、仕様中のpalpable contentのところの記述の趣旨を斟酌して、hidden属性付き子要素は「無い」ものとして扱って、判定してます。
<TAG> と </TAG> の間に空白文字しか含まれていません。 *3*
あるWWWブラウザで半角空白と異なる振る舞いをするからといって、全角空白 □ を利用して、<P>□</P> のように空白だけの要素を書いて桁揃えをしようとする試みが数多く行なわれています。これは、偶然うまくいくかも知れませんが、好ましくありません。しかし、これらが何らかの別の正当な意図的な目的で行なわれていないとも限りません。ここでは、全角空白の他に、半角カタカナ空白である     や、 も含めて空白文字とみなしています。
<TD> などの内容を空白だけにして、何らかの視覚効果を狙うのは、スタイルシートで行なうようにと、アクセス指針CSS技術文書に書かれています。この警告は減点されません。
<TAG>～</TAG> 内には空白以外に <BR> しか含まれていません。 *
<P> を <BR> のように使っていたら警告されたので <BR> に変えたら、今度は <BR> を <BODY>～</BODY> 内に書くことはできないと警告された。そこで <P><BR></P> と書いた。ということがあるのだそうです。
本質を理解しないまま満点を目指した結果なのですが、意図的に <P><BR></P> と書かないとも言いきれません。
<P> <TD> <TH> に対してだけ警告されます。この警告は減点されません。
<TAG> は不明なタグです。 *5*
文字どおり間違ったタグを書いています。スペルミスなどの可能性があります。多くの参考書で紹介されている <NOFRAME> というのは <NOFRAMES> の誤りです。また、<CENTER>～</CENTER> はあっても、<LEFT>～</LEFT> なんてのはありません。
チェックしているHTMLのヴァージョンではサポートされていないが、他のヴァージョンでサポートされているタグです。あまりこの警告が大量に出るようなら、DOCTYPE宣言が適切でない可能性があります。
このタグは、すたれつつあるタグです。将来はサポートされなくなる可能性があるので、使わないようにしましょう。例えば、次のように代替のタグを使います。
<CENTER> | → | <DIV align="center"> |
<DIR> | → | <UL> |
<MENU> | → | <UL> |
<ISINDEX> | → | <INPUT> |
<XMP> | → | <PRE> |
<APPLET> | → | <OBJECT> |
ただし、HTMLのヴァージョンによって警告されるタグが異なりますし、単純に要素名だけ替えればいいというわけではないので注意してください。
<TAG> はあまり薦められないタグです。スタイルシートを使いましょう。 *3*
HTML4.01では、<FONT> や <U> などが薦められないタグになっています。これらのタグは、文書構造を記述するという本来の目的からは外れたタグとして、スタイルシート(CSS1(J)/CSS2(J))を利用しなさい、ということです。それにしては、<B> や <I> などは外されていません。この警告は減点されません。
<TAG> は Another HTML-lint では正確な評価はできません。
MSIE5.0でサポートされている <XML> や、<HTML xmlns:namespace> で宣言される custom Element を正確に解釈することはできません。
<XML> は、HTML中にXMLを挿入するのに用いますが、Another HTML-lint ではXML名前空間等の解釈をすることはできません。<XML>～</XML> 内に書かれるタグは、開始終了タグの対応関係以外はチェックされません。この警告は減点されません。
改造者追記：XHTMLでの<TAG xmlns:namespace>およびそれによって定義づけられる<XXX:TAG>も同様です。なお、xmlns:namespaceによる名前空間はXHTMLの構文ですので、HTML構文で使うと不明タグとして警告され減点されます。
改造者追記：XHTMLで、他のXML規格の要素を<TAG xmlns=～>で組み込む場合も同様です。
改造者追記：HTML Living Standardでの<SVG>と<MATH>も同様ですが、上記のものよりは詳細な判定はしてます。ただし、不完全なため変なエラー判定が出ます（math要素内・svg要素内のimage要素がうまく扱えないため、その関連で警告が出る。svg要素内のa要素・title要素・script要素・style要素も同様。要素名等の大文字・小文字の判定もおかしいはず）。Nu Html Checkerでのチェックをお薦めします。
<BLINK> や <MARQUEE> といったタグは使うべきでないと、WAI で名指しで強く主張されています。
省略できない開始タグが書かれていません。ISO/IEC 15445 などでは、<HTML> を省略することができません。XHTML1(J)では、すべての開始タグは省略できません。
ここに <TAG> が省略されているようです。省略しないようにしましょう。 **
開始タグの省略は、HTMLではあまり行なわれないようですが、仕様上は省略が許されているタグがあります。<HTML> や <HEAD>、<BODY> などの開始タグは省略することができます。だからといって、省略はしないようにしましょう。
タグのひとつもないプレーンなテキストをHTMLとして評価しようとすると、省略可能なタグが補われて、次のようなHTMLだとみなされますが、<HEAD> に必要な <TITLE> が含まれていないので、正しいHTMLとはなりません。<TITLE> タグは省略可能ではないので、自動的に補うことができません。
<HTML> <HEAD> </HEAD> <BODY> テキスト </BODY> </HTML>
こんなのは勘弁して欲しいものです。
改造者追記：HTML Living Standardでは、table要素直下の子要素にtbody要素とtr要素が混在することを禁止してます。（XML構文では、このルールが直接適用されますが）、HTML構文では、tbody要素が省略可能要素であることから、tr要素を囲むtbodyが省略されてるみなしつつ、減点対象としてこの警告を出します。次の項目である無減点警告としなかったのは、「table要素直下の子要素にtbody要素とtr要素が混在してはならない」という規則に対する脱法行為的なものだからです。
改造者追記：減点率を下げた。
HTML4.0で拡張されたタグのうち、古いヴァージョンとの互換のために開始タグの省略できるものがあります。例えば、HTML3.2(J)などでの次のようなTABLEがそうです。
<TABLE> <TR><TD>うはうは</TD></TR> </TABLE>
これはHTML4.01では
<TABLE> <TBODY> <TR><TD>うはうは</TD></TR> </TBODY> </TABLE>
とみなされますが、<TBODY> と </TBODY> は省略できます。この警告は減点されません。
省略可能である終了タグは、たくさんあります。HTML3.2(J)では、次の終了タグは省略して構わないことになっています。他のHTMLではまた違います。
| </HTML> | |
| </HEAD> | |
| </BODY> | |
| </PLAINTEXT> | |
| </P> | |
| o | </DT> |
| o | </DD> |
| o | </LI> |
| </TR> | |
| o | </TH> |
| o | </TD> |
| o | </OPTION> |
これらのうち、多くの場合は省略して用いられる o の付いている 6種のタグ以外の終了タグを省略したときは、この警告が出ます。これらの終了タグは、積極的に省略せよ、という意味ではなくて、省略してもいいけどほんとは書いた方がいいんだよ、というものです。
</TR> が除外されています。HTML4.01(J)に挙げられている例の多くは省略されています。これは、Mozillaなどの一部のWWWブラウザが、</TR> 省略時にテーブルの入れ子などの処理を正しく行なえないのが除外の理由です。また、Mozillaとしてチェックした場合は、</TH> と </TD> も除外されます。
また、</P> が、過去との互換のために省略できるなどというのは間違いです。過去(HTML1.0)との互換性はありません。
例えば、<DL>～</DL> 中には <DT> と <DD> しか書けないので、
<DL> <DT>かくかくしかじか
のような場合でも、</DT> は、次の <DT> か <DD> か </DL> のいずれかの直前にあるとみなすことができます。一方、
<P>まるまるくまぐま
のようなときは、<P> の書ける場所があまり限定されていないので、</P> を、このHTMLを書いた人がどこに想定しているのかあまり明確ではありません。
<P>高名なある博士の論文に次のような記述があります。 <BLOCKQUOTE>金太郎と桃太郎は同一人物である。その根拠は…</BLOCKQUOTE> これを読んだときは目から鱗でした。</P>
これは、どう見ても <BLOCKQUOTE> が <P> の中に書けると誤解している書き方です。これは次のようにしてください。
<P>高名なある博士の論文に次のような記述があります。</P> <BLOCKQUOTE>金太郎と桃太郎は同一人物である。その根拠は…</BLOCKQUOTE> <P>これを読んだときは目から鱗でした。</P>
また、<P> を改行の意味で使用していることもあります。<P> は段落の意味のタグなので、これは好ましくありません。
～というわけです。<P> <TABLE>～
このようなとき、<TABLE> は <P> の中に書けないので、<TABLE> の前に </P> が省略されているとみなされ、<P> は <BR> じゃないと言われ、さらに開始タグと終了タグの間が空だと警告されます。これは次のように書きます。
<P>～というわけです。</P> <TABLE>～
このように、<P>～</P> の間に書いてはならないタグを書いていることが多いので気を付けましょう。
<P align="center"><HR></P>
などというおばかなコードを吐き出すHTMLエディタもあります。これはまったく意味不明なコードです。<HR> を <P> の外に出してください。<P>～</P> が空になったらその <P>～</P> は捨ててください。
ここから先は私見です。
<P> はパラグラフだ。パラグラフ中に引用など別のブロックを含めることは、上の金太郎の例もそうだが、よくあるであろう。例えば、
具体的には、
1. ごじらの場合
2. もすらの場合
3. ふらんしーぬの場合
というようなケースが考えられます。
なんてのを、HTML文法に則って構造化しようとすると、<OL> を <P> に含められないので
<P>具体的には、</P> <OL> <LI>ごじらの場合 <LI>もすらの場合 <LI>ふらんしーぬの場合 </OL> <P>というようなケースが考えられます。</P>
という風に書くと思うけど、これは、どう考えてもおかしい、と感じているのは私だけではないようだ。自然な構造は、
<P>具体的には、 <OL> <LI>ごじらの場合 <LI>もすらの場合 <LI>ふらんしーぬの場合 </OL> というようなケースが考えられます。</P>
という入れ子構造だと思うが、HTMLはこれを許してくれない。
改造者追記：減点率を下げた。
</LI> や </DT> などの省略が自明な場合に出ます。上の解説を参照してください。この警告は減点されません。
<P> を連続して
<P>ほにゃらら <P>へにょろろ
のように用いているとき、この場合「ほにゃらら」の後ろの </P> は省略が自明だとみなされます。「へにょろろ」の後ろの </P> は、さらに <P> が続けば自明な省略とみなされますが、そうでない場合は自明とはみなされません。
Laura Lemay のHTML本では </LI> は存在しないものとして解説されているけど、この本が書かれた時点のHTMLがそうだったからに過ぎず、現在のほとんどのHTMLでは </LI> は存在します。これを鵜呑みにして </LI> を存在しないものとしているおばかな参考書もあるので気を付けましょう。
ところが、残念なことにHTML4.0対応を謳ったHTML入門第2版でも「<LI> に終了タグは存在しない」と書かれているので注意してください。このシリーズ、初版から内容の全面的見直しをしてないようだ。
終了タグ </TAG> には属性を指定することはできません。 *6*
終了タグには、一切の属性を指定することはできません。
<TAG> には終了タグ </TAG> はありません。 *6*
<BR> のようなタグには終了タグ </BR> は存在しません。ただし、HTMLのヴァージョンによって、終了タグのあるものとないものがあります。例えば、HTML3.2(J)などでは <BASEFONT> に終了タグはありませんが、Mozillaの場合は </BASEFONT> が存在します。
XHTML1(J)ではすべてに終了タグが存在します。空要素タグは
<br /> <br></br>
のどちらで表記しても構いません。前者は、後者の短縮形です。空要素なので、
<br>むにゃむにゃ</br>
などと何か内容を入れることは当然できません。
<TAG>～</TAG> 内の先頭/末尾に空白文字があります。 *
これは、次のような書き方はしないように警告します。
<A href="～"> <IMG src="～"> </A>
開始タグ直後と、終了タグ直前に空白や改行を入れないようにしましょう、ということです。この例だと、古い多くのWWWブラウザでホットスポットを表現する下線が、イメージの右下に髭のように表示されます。
この例は次のように書きます。
<A href="～"><IMG src="～"></A>
開始タグ直後の空白については、例えば <LI> 直後に入れた場合、実装によってはリストの先頭が不揃いになることがあるようです。しかし、HTML4.01(J)には空白を先行させている例が沢山載っています。
Introduction to HTML3.2(J)には、開始タグ直後の改行と、終了タグ直前の改行は無視されるようなことが書いてあります。つまり、上の <IMG> の例は等価でなければなりません。しかし、既存の多くのWWWブラウザはこれを守っていません。
HTML4.01(J)では、開始タグ直後の空白や終了タグ直前の空白は表示されると思ってはいけないようなことが書いてあります。そのとおりならば、
<P>We offer free<A href="～"> technical support </A>for subscribers.</P>
なんて書くと、単語が繋がってしまうはずなので、こんな風に書くべきでないということになります。これは次のようにします。
<P>We offer free <A href="～">technical support</A> for subscribers.</P>
この警告は、状況を細分して減点したりしなかったり制御すべきなのですが、そこまでできていません。つまり、インライン要素の開始タグ直後の空白のみ減点し、他は非減点にすべきであろうと考えています。とりあえず、この警告は減点されません。
改造者追記：PRE要素・TEXTAREA要素は、先頭・末尾の空白もそのまま表示するので、必要な空白がどうか確認しましょう。また、PRE要素・TEXTAREA要素の開始タグ直後の改行文字は、HTMLだと削除され、XHTMLだとそのまま改行として表示されるということで、レンダリングに差が出ます。
</TAG> に対応する開始タグ <TAG> が見つかりません。 *6*
ほとんどの開始タグは省略できないので、それらの開始タグなしに終了タグは存在し得ません。開始タグを消したときの修正漏れの他に、タグの入れ子関係がおかしくなっているときの副作用のこともあります。
<TAGA> は NN行目の <TAGB> と重なり合っているようです。 *6*
次のように、開始タグと終了タグの関係が入り乱れているときにこの警告が出ます。
<P>むかしむかし<BIG>でかい桃が</P>どんぶらこ</BIG>
このような単純な間違いはいいのですが、タグの入れ子が深いときなど、ひとつタグを間違えただけで、この警告がたくさん出ることがあります。
入れ子にできるタグのレベルは、SGML宣言(J)の QUANTITY TAGLVL で指定されていて、たいてい 100です。
この警告に出てくる <TAG> は、そのタグでエラーが起こったことを示すだけです。<TAG> だけ 100レベルも入れ子になっているわけではありません。
NN行目の <TAG> に対応する終了タグ </TAG> が見つかりません。 *6*
省略できない終了タグを書いていないときに警告されます。よく、</A> を書いていないことがあります。WWWブラウザによっては適当に </A> を補ってそれなりのリンクが張られるものもありますが、全然うまくいかない場合もあります。この </A> を書いていないケースでは、<A> の中に <A> を書いていると警告されることも多いです。
省略できる終了タグについても目を通しておいてください。
<TAG>～</TAG> 内に普通のテキストを書くことはできません。 *6*
<HEAD> や <UL> などの要素には、決められたタグしか書けません。
<UL>なんじゃこりゃ</UL>
みたいに書くことはできないわけです。これは、
<UL><LI>なんじゃこりゃ</UL>
が、正解です。
HTML4.01 Strictでは、<BODY>～</BODY> 内にも普通のテキストを直接書くことはできなくなっています。つまり、
<BODY> 例えばこういう風に書く </BODY>
とは書けないのです。正しくは、次のようにします。
<BODY> <P> 例えばこういう風に書く </P> </BODY>
このように、<BODY> にはブロックレベル要素しか書けません。
<TAG> 内におかしな文字列 `XXX` があります。 *6*
タグの要素名や属性名は、(いわゆる半角の)英数字、ピリオド "."、ハイフン "-" から成り、先頭は英字です。HTML4.01(J)では、下線 "_" とコロン ":" も書けるようになっています。属性値に空白など他の文字を含めたいときなどは引用符で囲む決まりです。タグ内の引用符の外側に、これら以外の文字があったときに警告されます。よくあるのが、ハイフン "-" と下線 "_" を間違えているケースや、属性の区切りに全角空白を書いていたり、属性名を全角にしているケースです。ひとつでもこういうのがあると、そのタグ内でこのエラーがたくさん出ます。
予期しない "<" が現れたときの警告についても見てください。
XXXXXX では空要素タグを `<TAG />` と書くことはできません。 *5*
XHTML以外では、空要素タグを /> で閉じることはできません。
要素名や属性名の大文字小文字を統一するようにしましょう。 *
タグの要素名や属性名の大文字小文字は同一視されるので、次はすべて同じです(XHTMLを除く)。
<BLOCKQUOTE> <BlockQuote> <blockquote>
HTML中でこれらを大文字か小文字かどちらかに統一して書いていた方が美しかろう、という(多分に宗教臭い)警告です。要素名、属性名それぞれ独立にチェックされます。HTML4.01(J)のリファレンスでは、要素名は大文字、属性名は小文字で書かれていて、その理由は読み易くするためだ、と言ってます。
この警告は、Weblintを引き継いだだけの警告で、減点されません。
XML(J)では要素名や属性名の大文字小文字は区別されるので、どれでもいいというわけにはいきません。決められているとおりに大文字小文字のメリハリを付けて書く必要があります。XHTML1(J)では、要素名、属性名は小文字に決められているので小文字で書かなければなりません。
改造者追記：HTML Living Standardのmath要素内・svg要素内の諸要素については、正しいのにこのエラーが出ることがあります。
タグ <TAG> は小文字で書かなければなりません。 *5*
XHTML1(J)では、要素名は小文字で書かなければなりません。
改造者追記：HTML Living Standardのmath要素内・svg要素内の諸要素については、正しいのにこのエラーが出ることがあります。
<TAG> の属性 `ATTR` は小文字で書かなければなりません。 *5*
XHTML1(J)では、属性名は小文字で書かなければなりません。
改造者追記：HTML Living StandardのXML構文のmath要素内・svg要素内の諸要素については、正しいのにこのエラーが出ることがあります。
<TAG> に不明な属性 `ATTR` が指定されています。 *5*
間違った属性が指定されています。スペルミスなどの可能性があります。しかし、参考書があからさまに間違った解説をしていないとも限りません。例えば、Mozillaを解説したある参考書では、<LAYER> に名前を付けるのにNAME属性を使うよう指導しています。Netscape社のサイトを見ればわかりますが、これはID属性の誤りです。
改造者追記：HTML Living Standardの判定では、MicrodataとWAI-ARIAとRDFaの諸属性は、SVG要素内やMATH要素内の諸要素には書けないものとして扱ってます（SVG要素自体、MATH要素自体もダメ。ただし、WAI-ARIA関連属性は、SVG要素自体・MATH要素自体は、ＯＫ）。
改造者追記：HTML Living Standardで、math要素内・svg要素内のimage要素がうまく扱えないため、またsvg要素内のa要素・title要素・script要素・style要素も同様のため、この警告が出ることがあります。Nu Html Checkerでのチェックをお薦めします。
改造者追記：HTML Living Standardのdata-**属性は、**部分に使える文字に制限があります。コロン（：）は不可。ハイフン（-）、アンダーバー（_）、ピリオド（.）以外の記号類もほとんどダメ。漢字等の非アルファベット文字は使えますが、この改造版では対応しませんので、エラーになります。
<TAG> に XXXX 用の属性 `ATTR` が指定されています。 *5*
チェックしているHTMLのヴァージョンではサポートされていないが、他のヴァージョンでサポートされている属性です。あまりこの警告が大量に出るようなら、DOCTYPE宣言が適切でない可能性があります。
改造者追記：HTML Living Standardの判定では、MicrodataとWAI-ARIAとRDFaの諸属性は、SVG要素内やMATH要素内の諸要素には書けないものとして扱ってます（SVG要素自体、MATH要素自体もダメ。ただし、WAI-ARIA関連属性は、SVG要素自体・MATH要素自体は、ＯＫ）。
改造者追記：HTML Living Standardで、math要素内・svg要素内のimage要素がうまく扱えないため、またsvg要素内のa要素・title要素・script要素・style要素も同様のため、この警告が出ることがあります。Nu Html Checkerでのチェックをお薦めします。
<TAG> の属性 `ATTR` はあまり薦められない属性です。 *3*
この属性は、すたれつつある属性です。将来はサポートされなくなる可能性があるので、使わないようにしましょう。ここで指摘される属性には、スタイルシートによる代替はありません。特に<A>のTARGET属性は、その利用自体が薦められていません。フレームの利用や、強制的な方向付けはやめましょう。
XHTML1.0(J)では、<A>などのNAME属性は薦められていません。ID属性を使いましょう。XHTML1.1では、そのようなNAME属性は廃止されています。
改造者追記：すたれつつある属性というわけでなく、単純に「推奨されない属性」「指定すべきではない属性」についても、この警告を使いまわしてます。
<TAG> の属性 `ATTR` はあまり薦められない属性です。スタイルシートを使いましょう。 *3*
スタイルシート(CSS1(J)/CSS2(J))での代替を薦められている属性です。残念ながら、これらの属性すべてがスタイルシートで置き換え可能なわけではありません(CSS2では可能?)し、スタイルシートをサポートしていないWWWブラウザのためには使わざるを得ないとも思います。この警告は減点されません。
<TAG> の属性 `ATTR` は Another HTML-lint では正確な評価はできません。
MSIE5.0でサポートされている <HTML xmlns:namespace> を正確に解釈することはできません。
xmlns:namespace は、指定された namespace を <STYLE>～</STYLE> 内で定義し、<namespace:xxx>～</namespace:xxx> のように参照します。この警告は減点されません。
<TAG> の ATTR 属性の前には空白が必要です。 *6* または **
属性の指定を
<BODY bgcolor="#FF00FF"link="#808080">
のように続けて書いているときに警告されます。この例では link の前に空白がありません。
HTMLでは、なくても文法上エラーではありませんが、XHTMLでは文法違反です。
<TAG> で ATTR 属性の指定が繰り返されています。 *5*
タグで指定する属性は、同じものを何度も指定することはできません。
<BODY bgcolor="#FF00FF" bgcolor="#808080">
なんてのはだめです。
タグによっては、必ず指定しなければならない属性のあるものがあります。HTML3.2(J)の <BASE> のHREF属性などがそうです。また、<AREA> のALT属性は必須です。<IMG> のALT属性はHTML3.2では必須ではないのですが、HTML4.01では必要な属性となっています。ALT属性の使用を促す警告も見てください。
改造者追記：HTML Living Standardのimg要素ではALT属性は例外的に省略可能な場合がありますが、必須扱いで判定してます（HTML Living Standard仕様では、文法チェッカーは省略してよい例外にあてはまることが確実でない限りalt属性がなければエラーとして指摘せよ、って感じだし）。
改造者追記：HTML Living Standardのtime要素では、要素内テキストが所定書式に沿わない場合（当該テキストの前後に改行があってもダメ？＊）は、datetime属性が必須です。
＊記載時点でのW3Cのvalidatorの挙動ではそうなっている。
<TAG> で ATTRA 属性を使うときは ATTRB 属性も必要です。 *3*
NTT DoCoMo iモードでは、同時に指定しなければならない属性があります。
<A IJAM HREF>
<A TELBOOK KANA EMAIL HREF>
改造者追記：HTML Living Standardでは、○○属性がない場合は××属性は指定できないとか、××属性は○○属性がない場合は省略しなければならないといったものが結構あります。
<TAG> で ATTRA 属性と ATTRB 属性を同時に指定することはできません。 *3*
NTT DoCoMo iモード 4.0では、同時に指定してはならない属性があります。
<A IJAM>
<A ISTA>
<TAG> の ATTR 属性には属性値が必要です。 *5*
多くの属性は属性値を伴って指定されます。
<BR clear>
では不完全です。
<BR clear="all">
のように属性値を正しく指定しましょう。
<BR clear=>
なんて書いたときは別の警告が出ます。
改造者追記：HTML Living StandardのHTML構文では、属性値が空の場合は属性値を省略してもよいことになってますが、この改造版では対応できてません。
<TAG> の ATTR の属性値が指定されていません。 *6*
属性値が = の後ろに指定されていません。
<A name=>
のように書いてしまったときにこの警告が出ます。
<TAG> の ATTR の属性値が複数行に渡っています。 *
引用符で囲んだ属性値は、行をまたいで書いても構いません。改行はただの空白と同じ扱いです。
<AREA shape="rect" coords="10, 12,
50, 76">
とかいう具合なんですが、まあ、一応警告しときます。この警告は減点されません。
改造者追記：INPUT要素のvalue属性値の場合は、減点項目。HTML Living Standardでは、typeがtext, search, tel, passwordの場合は、value属性値の改行は禁止のため。
<TAG> の ATTR の属性値区切りの = 前後に空白が含まれています。 *
RFC1866(J)では、属性と属性値とを区切る = の前後には空白を含めてもいいことになってるんですが、それをわざわざ警告するHTMLチェッカも存在するのでこの警告があります。この警告は減点されません。
<TAG> の ATTR の属性値の引用符が閉じられていません。 *3*
属性値を引用符で囲んでいる場合、その中に ">" が現れると、タグが閉じられてしまう可能性があります。
<IMG src="～" alt="a>b">
のようなのは、
<IMG src="～" alt="a>b">
と、実体参照を用いて書くようにしましょう。これについては、RFC1866(J)で言及されていて、本来は間違いとは言えないのですが、実際に引用符を閉じ忘れている場合との区別が厳密にはつかないため、Another HTML-lint では文法的な間違いとしています。
<TAG> の ATTR の属性値が 'XXXX' と書かれていますが、"XXXX" の方が安全です。 *
属性値の文字列を囲む引用符には、二重引用符 "～" と単引用符 '～' のどちらでも使用できます。これらの使い分けは、主に二重引用符自身を表現したいときに、いちいち " と書くのがわずわしいので単引用符で囲む、というものです。
"We say "So!"" 'We say "So!"'
これらは、どちらも同じです。しかし、単引用符を解釈しないWWWブラウザが存在するそうです(MSIE for MacOS が該当します)。この警告は減点されません。
ところで、ある参考書に "～" 中に " を書くには \" とするなどと書いたのがありました。どうしてそんな解説が書けるのか不思議でなりません。JavaScript中などとごっちゃになってるんですかね。
<TAG> の ATTR の属性値 `XXXX` は引用符で囲まなければなりません。 *6*
属性値を必ずしも引用符で囲む必要はありません(XHTMLを除く)。値が英数字、ピリオド "."、ハイフン "-" から成り(いずれも半角の)、72文字以内の文字列のときは引用符で囲む必要はありません(実際はこれらの制限はSGML宣言(J)の QUANTITY NAMELEN で行われて、HTML4.01では 65536です)。そうでない文字列は、引用符で囲まなければなりません。-5 は囲まなくてもいいですが、+5 は囲まなければなりません。Cプログラマの方は、下線 "_" が含まれていないことに注意してください。
<A href="～" target=_top>
は
<A href="～" target="_top">
と書かなければなりません。ただし、HTML4.01(J)では、名前文字に下線 "_" とコロン ":" が追加されているので、_top を引用符で囲む必要はないのですが、他のHTMLのことも考えれば囲んだ方が安全です。
Laura Lemay の続HTML入門に、<FONT SIZE=+5> とか <HR WIDTH=90%> とかいう例が載っているけど、これらは間違いです。
<TAG> の ATTR の属性値 `XXXX` は引用符で囲んだ方が安全です。 **
HTML4.01(J)で、下線 "_" やコロン ":" を含む文字列を引用符で囲んでいないときにこの警告が出ます。他のHTMLのことも考えれば囲んだ方が安全です。
<TAG> の ATTR の属性値 `XXXX` が引用符で囲まれていません。 *
引用符で囲む必要のない裸で指定されている属性値に対して、注意を促します。これは、好みで全部囲まなきゃ気が済まないときなどにチェックするようにしましょう。それ以外ではたぶん不要です。この警告は減点されません。
<TAG> の ATTR の属性値 `XXXX` は空白文字が先行または後行しています。 *
決まった値や数値などを取る属性の値に空白を先行、後行させたときに出ます。
<P align=" center"> <UL type="disk "> <LI value=" 5 ">
これらが間違いかどうかはよく知らないのですが、文書記述言語SGML(内容は日本工業規格だからそれなりだけど、HTMLとしては無惨極まりない)の 6. 要素構造 によると、正しくないように読めます。
XHTML1(J)には、属性値の先行後行する空白は無視され、それ以外の連続する空白は単一の空白として扱われると書かれています。つまり、上の例はすべて正当です。
<TAG> の ATTR の属性値 `XXXX` はあまり薦められない値です。 *3*
この値は、すたれつつある値です。将来は指定できなくなる可能性があるので、使わないようにしましょう。
改造者追記：WAI-ARIAでは、abstractなroleはコンテンツ内では使わないようにと規定されてます。
改造者追記：HTML Living Standardでは、日時の機械可読な値を設定する場合は、data要素のvalue属性ではなく、time要素を用いることができます。
<TAG> の ATTR の属性値に空の値を指定することはできません。 *5*
決まった値や数値などを取る属性は、値に空を指定することはできません。このような属性は多数あります。
<P align=""> <UL type=""> <LI value="">
これらはいずれも正しくありません。<IMG alt=""> のように、空にできる属性もあります。
<IMG src=""> のようにURIを空にした場合は違う警告が出ます。
改造者追記：HTML Living Standardではboolean属性を「hidden=""」形式で記述できることが明記されましたが、属性値が空でもtrue状態であり、false状態を意味しないので、勘違いしてないかどうかご確認を。
<TAG> の ATTR の属性値が NN文字を超えています。 *5*
HTMLにおける属性値は 1024文字以内でなければなりません。これは、SGML宣言(J)の QUANTITY LITLEN で指定されるもので、HTMLごとに違っているのですが、1024に決め撃ちです。ちなみにHTML4.01では 65536です。
NTT DoCoMo iモードでは、次のような文字数の制限があります。
<OPTION VALUE> の文字数は 10文字以内。2.0では42文字以内、3.0では制限なし。
<A CTI> の文字数は 128文字以内。
<A SUBJECT> の文字数は 30文字以内。
<A BODY> の文字数は 500文字以内。
<A TELBOOK> の文字数は 20文字以内。
<A KANA> の文字数は 18文字以内。
<A EMAIL> の文字数は 50文字以内。
いずれも半角での文字数で、全角は半角2文字に勘定しています。
改造者追記：上限値を1024文字から65536文字に変更。
<TAG> の ATTR の属性値 `XXXX` は正しくありません。 *5*
属性値として、取り得る値が決められているものが多くあります。例えば <DIV ALIGN> には LEFT、CENTER、RIGHT のいずれか、<BR CLEAR> には ALL、LEFT、RIGHT、NONE のいずれかしか書けないなどです。
より詳しくは、HTML4.01(J)などを参照してください。
改造者追記：HTML Living StandardのID属性は制限がゆるくなってますが、反映してません。後方互換性の問題もあるので、厳しめの制限に従っておいた方が無難かと思われます。
改造者追記：HTML Living Standardにおいて、浮動小数点数を属性値とする属性については、「10e+1」のような指数部がある形式は正しくてもエラー判定してしまいます。
<TAG> の ATTR の属性値 `XXXX` は正しくありません。#RRGGBB の形式か決められた色の名前でなければなりません。 *5*
BGCOLORなどの色の指定は、"#00FF80" のような特別な形式でRGBを指定するか、決められている色の名前を指定します。HTML3.2(J)やHTML4.01(J)では 16色に名前が付けられていますが、MozillaやMSIEでは拡張されていて全部で 140色に名前が付いています。
<HEAD> の PROFILE の属性値は、DTD上は単一のURIとされています。 **
HEADのPROFILE属性は、DTD上はHTML4～XHTML1.1まで皆単一のURIと定義されています。
<!ATTLIST HEAD %i18n; -- lang, dir -- profile %URI; #IMPLIED -- named dictionary of meta info -- >
しかし、例えば HTML4.01(J) では、次のように述べられていて矛盾しています。
- profile = uri [CT]
- This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.
Another HTML-lint は、PROFILE属性を空白区切りの複数のURI列として評価します。この警告は減点されません。
<TAG> の ATTR の属性値 `XXXX` は使わない方が安全です。 *3*
XHTMLのID属性の値は、HTMLのそれとは異なっており、互換性もありません。下線 "_" から始まるID値は、XHTMLで使えますが、HTMLでは使えません。そのような値は避けるようにしましょう。
<TAG> の ATTR の属性値 `XXXX` は `xxxx` でなければなりません。 *5*
XHTMLでは、属性値の大文字小文字は区別されます。
<TAG> の ATTR の属性値は `XXXX` でなければなりません。 *5*
ごく一部の属性は、取り得る値が固定されているものがあります(DTDで#FIXEDが指定されているもの)。そのような属性では、固定されている値以外を指定することはできません。
<TAG> の ATTR は属性名と属性値が同一です。属性名を省略して属性値だけの指定にしましょう。 **
例えば、
<DL compact>
というのは、
<DL compact=compact>
の属性名の compact= の部分を省略した書き方です(属性値を省略しているのではありません)。したがって、本来ならばこのような省略しない書き方もできるはずなのですが、こういうのを解釈しないWWWブラウザもあるようです。省略した書き方をするようにしましょう。
XHTML1(J)では逆に、属性名を省略することはできません。
改造者追記：減点率を下げた。IE5.5でも非最小化表記に対応してることから、未対応ブラウザのシェアはほとんどないと推測されるため。
改造者追記：なお、HTML Living Standard仕様では、boolean属性の省略表記は、「hidden=""」の属性値の部分（=""）を省略したものとして定義されてます。
<TAG> の属性 `ATTR` で属性名を省略することはできません。 *5*
属性値の引用符を省略できないXHTML1(J)では、属性名を省略した短縮形を書くことはできません。例えば、
<dl compact>
というのは、
<dl compact="compact">
と書かなければなりません。
<TAG> の `XXXX` は属性名 ATTR が省略されていますが、うまく評価されないかも知れません。 **
属性名の省略は、何も compact=compact のような場合だけではなく、
<P center>
のように書いてもいいことになっています(XHTML1を除く)。これは、
<P align="center">
の省略形です。こういうのは、他に center という値を取る属性が存在しないときに可能なのですが、ここまで省略形をきちんと解釈してくれるWWWブラウザはなかなかないようです。
HTML4.01で <TABLE border> という風に書くと、これは、<TABLE frame=border> と解釈されるので注意してください。
実体参照 `&xx` の後ろには `;` を書きましょう。 *3*
実体参照というのは、< や & みたいな書き方のこと(正確には後者は文字参照)で、テキスト中に "<" や ">" など直接表現できない文字を書くときの方便です。実体参照は "&" で始まって ";" で終わります。SGMLでは、終わりのセミコロンは、省略が自明な場合は書かなくてもいいことになっています。例えば、
abc < xyz
実体参照 `'` は `'` と書くようにしましょう。 *3*
XHTML 1.0 (Second Edition) の C.16 に、後方互換性のために、' は使わないで ' と書くようにとされています。
XHTML では 16進数の文字参照は `ሴ` と小文字で始めなければなりません。 *3*
大文字小文字の区別されるXHTMLでは、16進数の文字参照も &#x と小文字で始めなければなりません。ሴ は誤りです。
"<" や ">" など実体参照で参照される名前は、HTMLごとに決まっています。大文字小文字が区別されるので、"&" のつもりで "&" と書くことはできません。WWWブラウザによっては同一視しているものもあるようですが、本来は間違いです。また、
abc<xyz
という風にしてしまうと、"<xyz" が実体参照だとみなされてしまいます。
CGI呼び出しでのパラメタ区切りは歴史的に & です。この & も & と書かなければならないことに注意してください。
<A href="uso.cgi?foo=1&bar=2">
ではだめです。
<A href="uso.cgi?foo=1&bar=2">
としなければなりません。& のままで動作するのは偶然です。上の例では、たまたま &bar という実体が定義されていないからに過ぎません。
<A href="uso.cgi?lt=1>=2">
では、
<A href="uso.cgi?lt=1>=2">
と解釈されてしまいます。
CGI呼び出し中でも実体参照を用いなければならないことは、RFC1866(J) 8.2.1 や、HTML4.01(J)などに書かれています。これにからんで、パラメタ区切りは "&" じゃなくて ";" にしましょうとも書かれていますが実際そうなりつつあるんでしょうか。少なくとも、Perlの非標準のライブラリ cgi-lib.pl や、標準の CGI.pm は、比較的新しい版ならどちらの区切りでも受け付けてくれます。
プロバイダ指定のCGIを利用する場合、この "&" を実体参照で解説しているものはまずありません。言われたとおりに書かなけりゃ動かないと脅されていると思いますが、"&" と書き直してみてください。動くはずです。これは、CGI側の制約ではなくWWWブラウザ側の問題だからです。ちなみに、古いOmniWeb1.0ではURL中の実体参照が展開されないそうです。
文字参照 `&#NNN;` は限界を超えた文字コードです。参照できるのは `&#MMM;` までです。 *6*
& のような文字参照で参照できる文字コードは、HTMLごとに定められています。例えば、HTML2.0やHTML3.2では 255まで、HTML4.0では 1114111までです。これはSGML宣言に記述されています。これより大きな値を与えると警告されます。MozillaやMSIEではチェックされません。DTDが存在しないからです。
文字参照 `&#NNN;` を使用することはできません。 *6*
J-SkyWeb用のHTMLでは、& のような文字参照を使用することはできません。
メタ文字 `X` は `&xx;` と書かなければなりません。 **
<SCRIPT> など一部のタグの要素を除いて、"<" や "&" などをテキスト中に直接書くことはできない、と思ってください。つまり、書きたければ実体参照を用いて、"<" や "&" と書きます。<PRE> 中にはそのまま書けると思っている人もいるようですが、<PRE> 中でも実体参照を用いなければなりません。
本当は、
abc & lt xyz
のように書くと、この "&" は実体参照ではないのが明らかなので、正しく "&" と表示されます。これはSGML的に誤りではないのですが、ちゃんと実体参照を用いて書くようにしましょう。
HTML4.01(J)では、16進数の文字参照が記述できるように拡張されています。水 のように行ないます。これは、SGMLにはありません。HTML4.0以上以外で 16進数の文字参照を行なうとこのエラーが出ます。これについての議論は、Proposed TC for WebSGML Adaptations for SGML K.4.1 Hexadecimal character reference にあります。
テキスト中の `"` は `"` と書きましょう。 *
安全のために、テキスト中の引用符 " を実体参照を用いて表現するように促す警告です。実際にはその必要はありません。この警告は減点されません。
<HTML> には LANG 属性を指定するようにしましょう。 *3*
<HTML> には、LANG属性を使ってその文書の言語を明示しておくことがWAIで薦められています。日本語の場合は次のようにします。
<HTML lang="ja"> <HTML lang="ja-JP">
HTTPレスポンスヘッダ中で Content-Language によって言語コードが指定されている場合は警告されません。
XHTML では xml:lang属性を使いますが、XHTML1.0では、両方を書くように薦められています。
LanguageCode は、ISO0639にあります。
<tag> に lang 属性を指定するときは xml:lang 属性も指定するようにしましょう。 *3*
<tag> に指定されている lang 属性の値と xml:lang 属性の値が食い違っています。 *3*
XHTML で lang属性と xml:lang属性の両方を併記したとき、その値は一致していなければなりません。
NN行目に指定されている LANG 属性は `xx` ですが、<TAG> の ATTR の属性値に日本語のような文字が含まれています。 **
WAIで、言語の変化をLANG属性で明示するように促されていますが、ここでは日本語の指定 LANG="ja" や LANG="ja-JP" 以外が指定してあるときに、属性値に日本語のような文字が含まれているかどうかを調べています。例えば、
<P lang="fr"> <IMG src="france.png" alt="フランスの地図"> </P>
というような場合です。また、属性の指定は、順不同でそのタグ内から有効となる(と明記されている)ので、
<INPUT lang="de" value="ドイツ人専用"> <INPUT value="ドイツ人専用" lang="de">
は、いずれも警告されます。
CHARSETが日本語の指定(JIS、EUC、Shift JIS)の場合か、CHARSET指定がなく日本語文書とみなされたときのみ警告されます。UTF-8の指定では警告されません。この警告は減点されません。
本来、言語の指定と文字コードは無関係なのですが、Another HTML-lint は主に日本語で書かれたHTMLを対象にしているので、このように文字コードによる判定を行なっています。
XHTML では xml:lang属性を使います。
NN行目に指定されている LANG 属性は `xx` ですが、テキストに日本語のような文字が含まれています。 **
WAIで、言語の変化をLANG属性で明示するように促されていますが、ここでは日本語の指定 LANG="ja" や LANG="ja-JP" 以外が指定してあるときに、テキストに日本語のような文字が含まれているかどうかを調べています。ただし、<SCRIPT>～</SCRIPT> 内などは除きます。
<P lang="es"> お元気ですか。今、スペインに来ています。 </P>
なんてのはだめです。
CHARSETが日本語の指定(JIS、EUC、Shift JIS)の場合か、CHARSET指定がなく日本語文書とみなされたときのみ警告されます。UTF-8の指定では警告されません。この警告は減点されません。
本来、言語の指定と文字コードは無関係なのですが、Another HTML-lint は主に日本語で書かれたHTMLを対象にしているので、このように文字コードによる判定を行なっています。
XHTML では xml:lang属性を使います。
<HEAD>～</HEAD> 内に <LINK REV="MADE" HREF="mailto:～"> が含まれていません。 *
Lynxなどの一部のWWWブラウザは、この情報を解釈して、このメールアドレスへ直ちにメールを出したりできます。HTML作者を明示するためにも、このタグは入れるようにしましょう。
しかし、古いMozillaは <LINK> タグをサポートしていないので、このタグをせっかく書いても、Another HTML-lint ではエラーが出ますが、気にしないでください。Mozilla4.0 になってようやく <LINK> がサポートされました。
と、指定を薦めているにもかかわらず、HTML4.01では、リンク形式に MADE は含まれていません。また、指定があれば mailto: である必要もありません。この警告は減点されません。
<HEAD>～</HEAD> 内に <LINK REL="NEXT" HREF="～"> などのナヴィゲーション用のリンクが含まれていません。 *3*
<LINK> を用いて、複数のHTML文書間の関係を記述することができます。
<LINK rel="INDEX" href="./index.html"> <LINK rel="NEXT" href="chapter3.html"> <LINK rel="PREV" href="chapter1.html">
ここでは、次のナヴィゲーション用のリンク形式の指定をチェックしています。どれも指定されていないときに警告されます。
| START | 開始ページ | |
| NEXT | 次のページ | |
| PREV | 前のページ | |
| CONTENTS | 目次ページ | |
| INDEX | 索引ページ | |
| GLOSSARY | 用語集ページ | |
| CHAPTER | 章 | |
| SECTION | 節 | |
| SUBSECTION | 小節 | |
| APPENDIX | 付録ページ | |
| HELP | ヘルプページ |
LynxやMosaicなどの一部のWWWブラウザはこれらを解釈することができます。このナヴィゲーション情報についてはWAIで用意するように指示されています。この警告は減点されません。
<LINK> の REL の属性値 `CONTENT` は `CONTENTS` の誤りだと思われます。 **
ナヴィゲーション用に目次ページを示すのは複数形の "CONTENTS" です。
<META NAME="ROBOTS"> に指定されている CONTENT 属性の値 `XXXX` はあまり薦められません。 *
検索ロボットについてHTML4.0中にも言及があります。CONTENT属性に記述できるのは、
"ALL"、
"NONE"、
"INDEX"、
"NOINDEX"、
"FOLLOW"、
"NOFOLLOW" で、しかもそれらの大文字小文字は区別されます (大文字小文字に関しては正誤表参照のこと)。
HTML Author's Guide to the Robots META tag も見てください。
ただし、この中にも Note the "robots" name of the tag and the content are case insensitive
という記述があったりで、かなり自己矛盾的な内容を含んでいます。
しかし、HTML4.01(J)からは、こういった大文字小文字に関する記述がきれいさっぱり削除されてしまっています。この警告は減点されません。
"NOARCHIVE" は、ロボットを排除する値としてよく利用されていますが、robotstxt.org の仕様には含まれていません。
<HEAD>～</HEAD> 内に <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="～"> が含まれていません。 **
現在日本語で書かれているHTMLの多くには、文字コードとして JIS、Shift JIS、EUC が利用されています。UTF-8 なども見られます。HTMLがどのコードで書かれているのかを明示するために、このタグを書くようにしましょう。
<META http-equiv="Content-Type" content="text/html; charset=ISO-2022-JP"> <META http-equiv="Content-Type" content="text/html; charset=Shift_JIS"> <META http-equiv="Content-Type" content="text/html; charset=EUC-JP"> <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
これらのどれか適切なものを書けばいいのです。こうしておくと、よくできた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 を導入しています。これは例えば、
hello.html.ja (日本語版のHTML)
hello.html.en (英語版のHTML)とあった場合、WWWブラウザの言語の設定によって hello.html という要求に対してどちらかを自動的に振り分けて送信するものです。Asahiネットでは、さらにこの言語優先機能に加えて実験的にリソースの文字セットの指定も行なえるようにしています。HTTPサーバがリソース中の(METAタグによる)情報を参照してCHARSETを決定するのはたいへんなので、このやり方はなかなか利に適っています。文字セットは次のように明示することができます。いずれも hello.html という要求で済みます。
hello.html.ja.jis (ISO-2022-JPで書かれた日本語版のHTML)
hello.html.ja.euc-jp (EUC-JPで書かれた日本語版のHTML)
hello.html.en.8859-1 (ISO-8859-1で書かれた英語版のHTML)これによって、サーバはHTTPレスポンスヘッダに適切なCHARSETパラメタを含めるので、HTML中の <META> による指定は不要です。興味のある人は、Asahiネットだからできるリソースの多次元的表現について などを参考にしてください。
蛇足ですが、あるURIが特定のリソースを指すわけではないことが、これらから明らかなことに注意してください。ひとつのリソースを複数のURIで指し示すことも可能なので、リソースとURIは多対多の関係にあります。決して一対一ではありません。
HTTPレスポンスヘッダにCHARSETパラメタが含まれている場合、この警告はチェックされません。 また、メディアタイプが application/xhtml+xml である場合は警告されません。
<META> に指定されている文字コードセット `XXXX` は IANA に登録されていません。 **
インタネット上で使うさまざまなコードは、Internet Assigned Numbers Authority (IANA) という組織が管理しています。ここで指定する文字コード(Character Sets)も管理しています。
よく、"charset=x-sjis" や "charset=x-euc-jp" を見かけますが、これらは、IANAには登録されていません。しかし、一部の古いWWWブラウザは、これらは解釈するけどIANAに登録されているやつは解釈しないというのもあります。Mozilla2.0などは、x-sjis は解釈するけれど Shift_JIS は解釈しません。これは、Shift_JIS の登録前に開発されたものだからです。日本語文書文字セットの指定方法などを参考にしてください。
登録前の文字セットの拡張として用いられる x-sjis、x-euc-jp などの x- で始まるものに関しては減点されません。
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="～"> に CHARSET を指定するようにしましょう。 **
CHARSETの指定はなくてもいいのですが、RFC1945やRFC2068によると、指定しなかった場合は、ISO-8859-1が仮定されることになっています。日本語を書く場合はきちんと指定しなければなりません。
メディアタイプが application/xhtml+xml である場合は警告されません。
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="～"> で CHARSET が指定されるより前に非ASCII文字が含まれています。 *5*
これは、RFC2070(J)やHTML4.01(J)に、もっとくどくど書かれていますが、ここでは単純にCHARSETが指定される前はASCIIしか書けない、と割り切ってしまっています。CHARSETで文字コードが指定されて始めて、そのリソースがどの文字コードで書かれているかわかるのです。<TITLE> で日本語を使っている場合は <META> よりも後ろに持って行ってください。
この警告は、<HEAD>～</HEAD> 内のみのチェックです。HTTPレスポンスヘッダにCHARSETパラメタが含まれている場合は警告されません。また、メディアタイプが application/xhtml+xml である場合は警告されません。
CHARSETで指定してあるコードが、US-ASCII、ISO-2022-JP のような 7bitコードのときに、非ASCIIコードが含まれていると警告されます。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
改行やタブ、JISのエスケープシーケンスなど以外の制御文字(0x00～0x1F)が含まれているときに警告されます。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
CHARSETにShift JISが指定してあるときに、半角カタカナ(JIS X 0201 のカタカナ部分)が含まれていると警告されます。また、JISのときは ^[(I という半角カタカナ用のエスケープシーケンスが現れると警告されます。EUCでも半角カタカナが表現できますが、チェックしていません。^[(I というエスケープシーケンスは、ISO-2022-JPでは規定されていません。つまり、ISO-2022-JPと宣言しておいてこのエスケープシーケンスを用いるのは誤りです。
なぜ半角カタカナがだめなのかは、RFC1468や半角カナの危険性やなぜ半角カナは嫌われるのか(メモ)などを参考にしてください。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
NTT DoCoMo iモード、特許出願用HTMLでは、半角カタカナの使用が許可されています。この場合、警告はされますが減点されません。
日本語のCHARSETが指定されているときや、CHARSETは指定されていないが日本語文書と判断されるとき、JIS X 0208:1997 で字形が例示されていない全角文字が含まれていると警告されます。例えば、丸付き数字やローマ数字、(株)などです。
JIS X 0208:1997 で字形が例示されているのは以下の区点コードです(かっこ内はJIS/SJIS)。
| 1-1 | (2121/8140) | ～ | 2-14 | (222E/81AC) | |
| 2-26 | (223A/81B8) | ～ | 2-33 | (2241/81BF) | |
| 2-42 | (224A/81C8) | ～ | 2-48 | (2250/81CE) | |
| 2-60 | (225C/81DA) | ～ | 2-74 | (226A/81E8) | |
| 2-82 | (2272/81F0) | ～ | 2-89 | (2279/81F7) | |
| 2-94 | (227E/81FC) | ||||
| 3-16 | (2330/824F) | ～ | 3-25 | (2339/8258) | 数字 |
| 3-33 | (2341/8260) | ～ | 3-58 | (235A/8279) | ラテン大文字 |
| 3-65 | (2361/8281) | ～ | 3-90 | (237A/829A) | ラテン小文字 |
| 4-1 | (2421/829F) | ～ | 4-83 | (2473/82F1) | ひらがな |
| 5-1 | (2521/8340) | ～ | 5-86 | (2576/8396) | カタカナ |
| 6-1 | (2621/839F) | ～ | 6-24 | (2638/83B6) | ギリシア大文字 |
| 6-33 | (2641/83BF) | ～ | 6-56 | (2658/83D6) | ギリシア小文字 |
| 7-1 | (2721/8440) | ～ | 7-33 | (2741/8460) | キリール大文字 |
| 7-49 | (2751/8470) | ～ | 7-81 | (2771/8491) | キリール小文字 |
| 8-1 | (2821/849F) | ～ | 8-32 | (2840/84BE) | 罫線素片 |
| 16-1 | (3021/889F) | ～ | 47-51 | (4F53/9872) | 第一水準漢字 |
| 48-1 | (5021/989F) | ～ | 84-6 | (7426/EAA4) | 第二水準漢字 |
区点コード 1-1 ～ 94-94 のうち、これら以外はすべて機種依存の文字とみなしています。
ここら辺の話については、情報交換用漢字符号系 JIS X 0208、日本語と文字コードや、使ってはいけない文字などを参考にしてください (注意: 84-5と84-6は、X 0208-1990 で追加されたので、X 0208-1983 を解説している文書には現われていません)。
NTT DoCoMo iモードでの絵文字や、特許出願用HTMLでの使用が許可されている一部の丸付き数字の場合は警告されません。
文書の先頭にBOM(Byte Order Mark)と呼ばれる制御コードが含まれています。UTF-8のBOMは、0xEF 0xBB 0xBF です。 この警告は減点されません。
XHTML では XML宣言中に encoding 指定をしましょう。 *3*
XHTML Media Types(J) によると、XHTMLでは、XML宣言中にencoding指定をすることが強く求められています。メディアタイプ application/xhtml+xml のときは、HTTPレスポンスヘッダにCHARSET指定がある場合でも同様です。
改造者追記：文字コード判定がUTF-8のときは（charset指定ではなく実際に記述されている文字からの判定なので、判定ミスもありうる）、警告対象外とした。XHTMLの仕様ではUTF-8のときはXML宣言は省略可能であるため。
改造者追記：HTML Living StandardのXML構文のときは、警告対象外とした。
指定されている文字コードセットは `XXXX` ですが、実際のコードは YYYY のようです。 *5*
せっかくCHARSETで文字コードを指定してあるのに、実際には異なる文字コードでHTMLが記述されています。このような文書は、CHARSETを正しく解釈するWWWブラウザではまったく読むことができません。日本語の指定(JIS、EUC、Shift JIS、UTF-8)のみチェックしています。XML宣言中のencoding指定の方が優先します。HTTPレスポンスヘッダにCHARSET指定がある場合は、さらにそちらを優先します。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
HTTPレスポンスヘッダに指定されている文字コードセットは `XXXX` ですが、<META> に指定されているのは `YYYY` です。 *5*
HTTPレスポンスヘッダでCHARSETが指定されている場合、その指定と <META> で指定されているものが矛盾しています。あるいは、XML宣言でのencoding指定と矛盾しています。日本語の指定(JIS、EUC、Shift JIS、UTF-8)のみチェックしています。
本来CHARSETの指定は、HTML中の <META> で明示するものではなく、HTTPレスポンスヘッダで行なわれるべきものなのですが、これはサーバ側で面倒をみなければならず、HTTPレスポンスヘッダにCHARSET指定を含めていないサーバは多数存在します。詳しくは「charsetパラメタの勧め: HTMLにおける文字符号化スキームの明示方法」を参照してください。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
HTTPレスポンスヘッダに CHARSET 指定が含まれていません。 *3*
HTTPレスポンスヘッダ中に CHARSET 指定をすべきです。 XHTML Media Types(J) でも強く求められいます。 しかし、これはサーバ側の問題です。 HTTP経由のチェックのときのみ警告されます。
<META> に指定されている CONTENT-TYPE が text/html ではありません。 *5*
text/html というのは、インタネットメディアタイプ(Internet Media Type)と呼ばれるインタネット上を流れるデータがいったいどんな種類のものかを表わす識別子で、これも IANA(Internet Assigned Numbers Authority) が管理しています。HTMLは text/html です。区切り文字のセミコロンを、誤ってコロンにしていたりするとこの警告が出ます。(XHTMLではRFC3236を受けて application/xhtml+xml もOKです)
XHTMLでは text/xhtml だと誤解されている方もいらっしゃるようですが、それは違います。そのようなメディアタイプは定義されていません。
HTTPレスポンスヘッダに指定されているメディアタイプは `xxxx/xxxx` ですが、<meta> に指定されているのは `yyyy/yyyy` です。 *5*
現在HTMLとして受け付けられるメディアタイプは、text/html と application/xhtml+xml です。HTTPレスポンスヘッダに指定されているメディアタイプと<meta>に指定されているそれが食い違っています。しかし、そもそも application/xhtml+xml では、<meta http-equiv> を記述すべきではありません。
指定されているメディアタイプ xxxx/xxxx は YYYYYY には指定しないようにしましょう。 *3*
XHTML Media Types(J) によると、HTMLに対して application/xhtml+xml を指定するのは禁止され、XHTML1.1に対して text/html を指定することを推奨していません。 XHTML1.0に対しては警告されません。
メディアタイプ application/xhtml+xml には <meta http-equiv> を記述すべきではありません。 *4*
XHTML Media Types(J) によると、メディアタイプが application/xhtml+xml である文書では <meta http-equiv> を記述すべきではないとされています。
<META HTTP-EQUIV="CONTENT-TYPE"> は NN行目にもありました。 **
誤りではないのかも知れませんが、一度にしておいた方が無難でしょう。
HTTP-EQUIV="REFRESH" に対しても同様の警告が出ます。
<TAG> を使うときは <HEAD>～</HEAD> 内に <META HTTP-EQUIV="CONTENT-XXXX-TYPE" CONTENT="～"> を指定するようにしましょう。 *3*
HTML4.01(J)には、スクリプトを使用する場合は <META> 内にベースとなるスクリプト言語を明示しておくように書かれています。
<META http-equiv="Content-Script-Type" content="text/javascript">
のように、<SCRIPT> が現れる前に宣言します。個々の <SCRIPT> に指定する言語は、必ずしもこれと同一である必要はありません。
また、スタイルシートを使用する場合も、ベースとなるスタイル言語を明示しておくように書かれています。
<META http-equiv="Content-Style-Type" content="text/css">
この警告は、<STYLE> タグに対する警告で、他のタグ中に埋め込む STYLE 属性に対してはもっと厳しい警告が出ます。ONCLICK 属性などに対しても同様です。
ATTR 属性を使うときは <HEAD>～</HEAD> 内に <META HTTP-EQUIV="CONTENT-XXXX-TYPE" CONTENT="～"> を指定しなければなりません。 *5*
スクリプトのイベント処理で利用する ONCLICK だとか ONBLUR だとかの属性を利用するときは、<META> でそのスクリプト言語を指定しておかなければなりません。このことは、HTML4.01(J)に明記されています。Javascriptならば、
<META http-equiv="Content-Script-Type" content="text/javascript">
というような宣言を含めておきます。
いろいろなタグの属性として埋め込まれる STYLE 属性を利用するときは、<META> でそのスタイル言語を指定しておかなければなりません。このことは、HTML4.01(J)に明記されています。CSSならば、
<META http-equiv="Content-Style-Type" content="text/css">
というような宣言を含めておきます。HTML4.01(J)には、指定がない場合は text/css が採用されることが期待できるように書かれているのですが、指定しなくてもいいわけではありません。
<META> に HTTP-EQUIV 属性と NAME 属性の両方を指定することはできません。 *5*
HTML4.01(J)では、HTTP-EQUIV 属性は NAME 属性の代わりとして使われるものとされています。つまり、これらを併記することはできません。
<META> に CONTENT 属性を指定するときは HTTP-EQUIV 属性か NAME 属性を指定しなければなりません。 *5*
<META> には、CONTENT 属性が必要ですが、HTML4.01(J)では、META要素は名前と値とを対で指定するように書かれています。つまり、CONTENT 属性だけでなく、HTTP-EQUIV 属性または NAME 属性が必要です。このような、どちらかが必要という指示は、DTDでは表現できません。
ATTRA 属性を使うときは ATTRB 属性も指定しましょう。 *3*
スクリプトのイベント処理では、装置非依存性を確保するために、次の属性は対で使用するように、アクセス指針技術文書4.12.2(J)で薦められています。
| onmousedown | + | onkeydown |
| onmouseup | + | onkeyup |
| onclick | + | onkeypress |
改造者追記：無減点に変更。特に、onclickイベントの場合は、Enterキーにも反応する実装が多くなってきた。また、onkeypressイベントは、実装によっては、タブキーによるフォーカス移動を妨げる可能性があるため、かえって不具合となる場合もありうる。
<META HTTP-EQUIV="REFRESH"> を利用しての自動的なページ更新は避けましょう。 *3*
WAIでは、REFRESHによる自動的なページの更新は行なわないように書かれています。これは、利用者の意思が無視されてしまうのが主な理由です。
<META HTTP-EQUIV="REFRESH" CONTENT="～"> を利用するときは同等のリンクも用意しましょう。 *3*
自動書き換え機能をサポートしていないユーザエージェントのために、通常のリンクなどによって移動できるようにしておく必要があります。このことは、HTML4.01(J)に記述されています。しかし、WAIでは、そもそもREFRESHによる自動的な方向付けを行なうことを推奨していません。
なお、HTML4.01(J)には次のようなREFRESHの指定方法が記述されています。
<META http-equiv="REFRESH" content="3,jump.html">
しかし、次のような書き方が多く流通しているようです。
<META http-equiv="REFRESH" content="3;URL=jump.html">
これは、どちらが正しいのでしょうか。規定などはなく、どちらも正しいのでしょうか。問題は、"URL=jump.html" というのがURIとして正しいので、両者が正しいとするとあいまいさが生じてしまいます。Another HTML-lint では、とりあえず、区切り文字が "," か ";" かで区別するようにしてあります。
<SCRIPT>～</SCRIPT> 内の要素はすべてコメントで囲んだ方が安全です。 **
<SCRIPT>～</SCRIPT> 内には、JavaScript など、HTMLとは構文上無関係な構文のテキストが含まれます。<SCRIPT> タグを解釈しないWWWブラウザも多いため、もし何の工夫もしないと、JavaScript などのプログラムがそのまま表示されてしまいます。そこで、JavaScriptでは次のような書き方をします。
<SCRIPT type="text/javascript"> <!-- ここからスクリプトを見えなくする JavaScriptステートメント... // ここまで見えなくなる --> </SCRIPT>
ここで、コメント末の --> がJavaScriptのコメント // の後ろにあることに気を付けてください。// を書かないで --> だけだと、-- がJavaScriptの演算子に解釈されて、構文エラーになってしまいます。JavaScriptの演算子 -- は、HTMLのコメント中でうまくない振る舞いをするかも知れませんが、おそらくWWWブラウザは、コメント中の -- をHTMLの仕様書とは違う実装で処理しているので大丈夫なのでしょう。HTML4.01(J)では、コメント中に -- は書かないようにとされています。これは、このようなCDATA中の -- を考慮してのことかも知れません。
次のように書いても正しくコメントアウトされません。
<SCRIPT type="text/javascript"> //<!-- ここからスクリプトを見えなくする JavaScriptステートメント... // ここまで見えなくなる --> </SCRIPT>
ちょっと考えれば最初の // が残ってしまうのがわかるでしょう。
スクリプトとしては、<!-- は、その行末までが無視されるので、次のようなことが可能だとしている参考書があります。
<SCRIPT type="text/javascript"> <!-- --> <H1>JavaScriptがサポートされていないよ</H1> <!-- JavaScriptステートメント... // --> </SCRIPT>
<NOSCRIPT> はあとから追加されたので、古いWWWブラウザではサポートされていないことがあり、<NOSCRIPT> を使わなくても、<SCRIPT> 非対応のWWWブラウザのことを考慮できるということなんですが、"</" を <SCRIPT> 中に書くことはできないので、あまりたいしたことはできません。つまり、上の例は正しくありません。
JavaScript 以外で、Tcl、VBScript の場合は次のようにします。
<SCRIPT type="text/tcl"> <!-- ここからスクリプトを見えなくする Tclステートメント... # ここまで見えなくなる --> </SCRIPT>
<SCRIPT type="text/vbscript"> <!-- ここからスクリプトを見えなくする VBScriptステートメント... ' ここまで見えなくなる --> </SCRIPT>
<STYLE>～</STYLE> に対してもこのエラーが出ます。この場合は、単純に内容をすべてコメントで囲めばいいのです。
<STYLE type="text/css"> <!-- /* ここからスタイルを見えなくする */ スタイル記述ステートメント... /* ここまで見えなくなる */ --> </STYLE>
XHTML1(J)では、<SCRIPT> や <STYLE> の内容がCDATAから#PCDATAに変更されたので、この手法を適用するだけではうまくありません。マーク区間を利用してください。
また、そのためにそもそもコメントで囲む記述をすること自体が問題となります。外部にファイルを用意するよう促す警告を見てください。
改造者追記：無減点に変更。styleやscriptの中身をそのまま表示してしまうようなブラウザは古いガラケーぐらいしか想定できなくなってきたため。
<SCRIPT>～</SCRIPT> 内に `</` を直接書くことはできません。 *6*
SGML的には、<SCRIPT> や <STYLE> の内容の終わりは、</SCRIPT> や </STYLE> タグではありません。終了タグ開始記号 </ です。したがって、JavaScriptなどで文字列として "</A>" というように "</" を含むものを直接記述することはできないことになっています。ではどうするかというと、何等かのエスケープ処理をしなければなりません。
"<EM>This will work</EM>" という文字列を考えてみましょう(HTML4.01(J)から引用)。JavaScriptの場合は次のようにします。
<SCRIPT type="text/javascript">
document.write ("<EM>This will work<\/EM>")
</SCRIPT>
Tclの場合は次のようにします。
<SCRIPT type="text/tcl"> document write "<EM>This will work<\/EM>" </SCRIPT>
VBScriptの場合は次のように、Chr() 関数を使って対処します。
"<EM>This will work<" & Chr(47) & "EM>"
要するに、とにかく "</" という列が現れなければいいので、JavaScriptでの
"<EM>This will work<"+"/EM>"
のようなやり方も有効です。また、例えばJavaScriptのコメント内だからといって例外ではありません。
// <EM>comment</EM>
などと書くことはできません。
HTML4.01(J)には </ にアルファベットが続くときに終わりとなると書かれていますが、Another HTML-lint ではそこまでは見ていません。
改造者追記：HTML Living Standardでは、上記ほど厳格ではないようだ（<SCRIPT> や <STYLE>の終了タグに該当しなければＯＫ）が、この警告は残してある。
<SCRIPT>～</SCRIPT> 内に `XX` を書くときは外部にスクリプトを用意しましょう。 *3*
HTMLで、<SCRIPT> や <STYLE> 内に、次のような文字を書くときは、外部にスクリプトファイルやスタイルファイルを用意するようにしましょう。
< |
& |
]]> |
-- |
これは、XHTMLで <SCRIPT> や <STYLE> の仕様が変更になるのを考慮してのことです。XHTML1.0 C.4 に記述されています。
-- が含まれているために、全体をコメントで囲むようなテクニックも危険なものになっていることに注意してください。XHTML以外ではこの警告は減点されません。
<SCRIPT>～</SCRIPT> 内にコメントを書くと、本当にコメントとして扱われます。 *3*
XHTMLでは <SCRIPT> や <STYLE> の内容が #PCDATA です。コメントはコメントとして解釈されてしまうので、旧来のテクニックは使えません。外部にスクリプトファイルやスタイルファイルを用意するようにしましょう。
<SCRIPT> タグがありますが、<NOSCRIPT> タグがありません。 *4*
HTMLのヴァージョンによっては、<SCRIPT> に対して <NOSCRIPT> がない場合にこの警告が出ます。
この警告は、WAIで守らなければならない事柄とされています。<NOSCRIPT> はあとから追加されたので、Mozilla2.0などの一部の古いWWWブラウザでは <SCRIPT> はサポートするけども <NOSCRIPT> をサポートしていないことがあります。このようなときは、スクリプトが有効なときでも <NOSCRIPT> 内が表示されてしまうことに注意してください。
また、WAIに示されているのは、重要な情報や機能を持っているスクリプトに対して <NOSCRIPT> を用意しなさいということです。実際にはONCLICKなどの表示を伴わないイベント処理に使われることも多く、これに対する <NOSCRIPT> が必要かというと、必ずしもそうとは言えません。というわけで、この警告はWAIで必須とされているにもかかわらず減点されません。
改造者追記：HTML Living Standard仕様書では、スクリプト未対応ブラウザ向けの記述をスクリプトで消す方法が推奨されてるので、HTML Living Standardはこの警告の対象外としてます。
<TITLE> の内容は 64文字以内に収めるようにしましょう。 *3*
仕様上は文字数制限などないのですが、あまり長いタイトルはWWWブラウザによってちょん切られることがあるそうです。しかし、最低でも 64文字は可能なように、とのお達しがRFC1866(J)にあります。HTML4.01(J)にはこのような記述は見当たりません。
<BODY> での色指定が不完全です。XXX、YYY 属性も含めるようにしましょう。 *3*
多くのHTMLで、<BODY> で指定できる色の属性には、BGCOLOR、TEXT、LINK、VLINK、ALINK があります。MozillaなどのWWWブラウザでは、これらを無視して独自に指定できるものもあります。このとき、HTML中の指定が中途半端だと、WWWブラウザでの指定とを混在させたときにうまくないことがあります。例えば、<BODY bgcolor="white"> とだけ指定してある場合、WWWブラウザ側で黒地に白字なんて指定になっていると、そのHTMLがまったく読めないという事態に陥ります。このようなことを避けるため、色指定をする場合は、なるべく全部を指定するようにしましょう。HTML4.01(J)にも似たような注意書きがあります。
スタイルシート中で色指定している場合も似たようなことが起こり得るので注意してください。Another HTML-lint では、スタイルシートの内容まではチェックできません。
<BODY style="background: #FFFF00">
などとしている場合は、チェックできません。
<BODY> で BACKGROUND 属性を指定したときは BGCOLOR 属性も指定するようにしましょう。 **
<BODY> で背景画像を指定してあるとき、そこに書かれている文字はその背景画像上でうまく読めるように選ばれているはずです(意図的に背景に溶け込ませることもありますけど)。このとき、BGCOLOR属性を指定していないと、WWWブラウザが画像を表示しない設定などになっていると、その文字が読めなくなってしまう可能性があります。
<TAG ATTR> の色指定が <TAG BGCOLOR> の色と同じです。 *3*
例えば、
<BODY background="hogehoge.gif" bgcolor="#FFFFFF" text="#FFFFFF">
のような場合、背景画像の読込みでうまく文字が読めるようになるのでしょうが、背景画像を表示しない(できない)環境では、文字が全く読めなくなってしまいます(意図的に読めなくしていることもありますけど)。警告は、背景画像の指定とは無関係に行なわれます。また、
<BODY bgcolor="#FFFFFF"> <TABLE bgcolor="#FF0000"> <FONT color="#FFFFFF">
のような指定は、読むことができません。
<TAG ATTR> の色指定と <TAG BGCOLOR> の色は明度差または色差が不十分です。 *3*
背景色と前景色の明度差または色差が不十分です。 ここでは、Techniques For Accessibility Evaluation And Repair Tools にある方法で明度差、色差が十分か判定しています。それは次のような方法です。
ここで、前景と背景の明度差が 125未満のとき、または色差が 500未満のときにコントラスト不足として警告されます。
神崎正英氏の「色の組み合わせをチェックしてみる」が役に立つでしょう。
背景画像との関係や、スタイルシート中での色はチェックできません。
<TAG ATTR> の色指定と <TAG BGCOLOR> の色は輝度比が不十分です。 *3*
背景色と前景色の輝度比が不十分です。 ここでは、Web Content Accessibility Guidelines 2.0 にある方法で輝度比が十分か判定しています。それは次のような方法です。
ここで、レベルAAでは 4.5以上の輝度比が、レベルAAAでは 7以上の輝度比が必要とされています。 ただし、WCAGにあるように、大きいテキストのときなどの例外は処理していません。 また、背景画像との関係や、スタイルシート中での色はチェックできません。
<TAG> の XXX 属性の値 `XXXX` は NN行目ですでに使われています。 *5*
各タグに付けることのできるID属性は、ひとつのHTML中で重複した名前を付けることはできません。また、ID属性の値は、HTMLでは大文字小文字区別されません。XHTMLでは区別されます。
NN行目で参照されている <TAG> の ATTR 属性の ID `XXXX` は定義されていません。 *5*
HTML4.01での <LABEL> のFOR属性などの値は、他のタグのID属性として指定されていなければなりません。
NTT DoCoMo iモードでは、<A IJAM> で指定したIDが、<OBJECT ID> に対応していなければなりません。
<TAG> の NAME 属性の値 `XXXX` は NN行目ですでに使われています。 **
<FORM> の要素である <INPUT> や <TEXTAREA> などは、NAME属性で名前を付け、その設定情報をVALUE属性の値と対で、CGIなどに渡せるようになっています。TYPE=TEXTなどのように、VALUE属性の値が固定的でないものに対して、同じ名前の要素がひとつのFORM内で複数存在すると、CGI側ではそれらを区別できません。
しかし、HTML4.01(J)には、チェックボックスとラジオボタン以外のフォームコントロールについて、NAME属性の一意性について何も言及がありませんが、RFC1866(J) 8.1.2.7 にはSUBMITで同じNAMEを使ったような例があります。つまり
<INPUT type="submit" name="command" value="Search"> <INPUT type="submit" name="command" value="Replace">
のように書けるということのようです。また、NAME属性省略時には、TYPE属性の値と同じ値が採用されるようなのですが、定かではありません。SUBMITにNAMEがない場合は無効 (If the NAME attribute is not present, this element does not contribute a form field.
) だとされています。
VALUE属性の値が固定的な、TYPE=RADIO/CHECKBOX/SUBMIT/RESET/BUTTON/IMAGEとHIDDENについては警告されません。
<TAG> の直後に空白以外のテキストを書くことはできません。 *3*
<FIELDSET> の直後には普通のテキストが書けることになっていますが、ここには空白以外を書くことはできません。これはDTD中にコメントされています。次はHTML4.01のDTDからの引用。
#PCDATA is to solve the mixed content problem,
per specification only whitespace is allowed there!
<INPUT TYPE="RADIO"> に CHECKED 属性が指定されていますが、NN行目ですでに指定されています。 *5*
<INPUT type="radio"> で、同じ名前のラジオボタン、つまり同じグループのラジオボタンに付けられるチェックはひとつだけです。
どの <INPUT TYPE="RADIO" NAME="YYYY"> にも CHECKED 属性が指定されていません。 *3*
同じグループのどの <INPUT type="radio"> にもチェックが付いていません。
HTML4.01(J) では、どれかひとつにチェックを付けた方がよいとされています。
どの <OPTION> にも SELECTED 属性が指定されていません。 *3*
同じ <SELECT> 内のどの <OPTION> にもSELECTED属性が付いていません。
HTML4.01(J) では、どれかひとつにSELECTEDを付けた方がよいとされています。
<OPTION> に SELECTED 属性が指定されていますが、NN行目ですでに指定されています。MM行目の <SELECT> に MULTIPLE 属性を指定してください。 *5*
<OPTION> に複数のSELECTED属性を付けるには、<SELECT> タグでMULTIPLE属性を指定しなければなりません。
NTT DoCoMo iモード 1.0では、複数SELECTED属性を指定することはできません。
ひとつの <SELECT> 中に指定できる <OPTION> は 20件までです。 *5*
NTT DoCoMo iモード 1.0では、<OPTION> による選択肢は20件までが指定可能です。
<TAG> には初期値となるテキストを指定しておきましょう。 *3*
<INPUT type="text"> や <TEXTAREA> には、何か初期値となるようなテキストをあらかじめ書いておくことがWAIで薦められています。その理由に、空だと正しく処理できないWWWブラウザの可能性が示されています。
改造者追記：HTML Living Standardでは、type="text"のほか、placeholder指定可能typeについて警告されます。
改造者追記：placeholder属性が指定されてる場合は、警告されません。
<BUTTON> には TYPE 属性を指定するようにしましょう。 *3*
ISO/IEC 15445では、<BUTTON> のTYPE属性は省略しないようにとされています。
<BUTTON> に用いる <IMG> には USEMAP 属性を指定することはできません。 *5*
HTML4.01(J)では、<BUTTON> にイメージを貼り付けるとき、それをイメージマップにすることはできないことになっています。ISMAP も同様です。
<TAGA> をここに書くことはできません。NN行目の <LABEL> 内には MM行目に <TAGB> が含まれています。 *5*
フォームコントロールをラベル付けするには何通りか方法がありますが、<LABEL> の要素にフォームコントロールを直接含めてしまうやり方があります。このとき、<LABEL>～</LABEL> 内には、ひとつのコントロールしか含めることができません。HTML4.01(J)を見てください。
FOR 属性の含まれない <LABEL>～</LABEL> 内にはフォームコントロールを指定しなければなりません。 *5*
<LABEL> はフォームコントロールに付加属性を付けるためのもので、どれかひとつのフォームコントロールと関連付けられていなければなりません。その方法は、<LABEL> の要素に指定する方法と、FOR属性によってフォームコントロールのID属性と関連付ける方法があります。つまり、FOR属性のない <LABEL> は、要素の内容にフォームコントロールを含んでいなければなりません。
<TAG> の ID 属性の値と NN行目の <LABEL> の FOR 属性の値が食い違っています。 **
<LABEL> の要素にフォームコントロールを書いたとき、そのフォームコントロールはその <LABEL> に関連付けられることになっていますが、そこにさらにFOR属性やID属性を指定したときにどのように解釈されるのかについて、HTML4.01(J)には言及がありません。
考えられる組み合わせは次のようになります。
<LABEL> <INPUT> </LABEL>
<LABEL for="A"> <INPUT> </LABEL>
<LABEL> <INPUT id="A"> </LABEL>
<LABEL for="A"> <INPUT id="A"> </LABEL>
<LABEL for="A"> <INPUT id="B"> </LABEL>
この解釈は間違っているかも知れません。k16@chiba.email.ne.jp までご指摘ください。
<TAG> には TABINDEX 属性を指定するようにしましょう。 *3*
アクセス性向上のために、フォームコントロールの <INPUT>、<TEXTAREA>、<BUTTON>、<SELECT> にはTABINDEX属性を付けて入力順序を指定するようにWAIで薦められています。この警告は減点されません。
WAIには、<A> にも条件付でTABINDEX属性を付けるように書かれていますが、ここでは除いています。
<TAG> には ACCESSKEY 属性を指定するようにしましょう。 *3*
アクセス性向上のために、<A>、<LABEL>、<LEGEND>、<AREA> などのリンク用のタグ、<INPUT>、<TEXTAREA>、<BUTTON> などのフォームコントロールには、ACCESSKEY属性を使って、キーボードショートカットを用意しておくことがWAIで薦められています (<A>に対しては別の警告が出ます)。この警告は減点されません。
<A accesskey="C" href="doc.html">XYZ company home page</A>
accesskey="XYZ" のように複数文字を指定することはできません。
指定するキーの一意性に関しては、HTML4.01(J)には記述されていません。ユーザエージェントによっては、同じアクセスキーを持つコントロールは、それらの中で次々と移動するように実装されているようです。しかし、17.11.2(J)には、<A> では直ちにリンク先に飛び、ラジオボタンの状態も直ちに変化する、ようなことが書かれています。これは、アクセスキーはアクションを起こすためのもので、コントロールの移動を行なうためのものではないということです。同じアクセスキーが指定された場合の議論がないのはどういうわけでしょうか。
ラベルと関連付けられているフォームコントロールでは、フォームコントロール自身にACCESSKEY属性がなくても、ラベルにあればいいことに注意してください。ラベルとフォームコントロールの関連付けの方法は、<LABEL> の要素としてフォームコントロールを書く方法と、<LABEL> のFOR属性とフォームコントロールのID属性で関連付ける方法があります。これについては別の警告のところに解説があります。
関連付けられたラベルとフォームコントロールにACCESSKEY属性を指定するときの組み合わせは次のようになります。
<LABEL> <INPUT>
<LABEL accesskey="A"> <INPUT>
<LABEL> <INPUT accesskey="A">
<LABEL accesskey="A"> <INPUT accesskey="A">
<LABEL accesskey="A"> <INPUT accesskey="B">
<TAG> には TITLE 属性を指定するようにしましょう。 *3*
アクセス性向上のために、<ABBR>、<ACRONYM> には、TITLE属性を書くようにWAIで薦められています。
この警告は減点されません。<FRAMESET> や <FRAME> に関しては、書かなければならないとされていて、違う警告が出ます。
<TAG> には等価な内容か代替コンテンツ、または少なくても未対応ブラウザ向けの説明テキストなどを書くようにしましょう。 *4*
<OBJECT> には、次のように要素の内容に適当な説明を書くように求められています。
<OBJECT data="magnifyingglass.gif" type="image/gif">Search</OBJECT>
これは、アクセス指針技術文書4.7.1(J)や4.8.1(J)にあります。
改造者追記：HTML Living Standardでは、OBJECT要素の内容は代替コンテンツの役割を果たすと定義されてます。また、AUDIO要素・VIDEO要素では、その内容は未対応ブラウザ向けコンテンツを記述するものとされてます。CAVAS要素では、その内容は代替コンテンツとなるとされてます。いずれも、未対応ブラウザ向けに記述しておくことが望ましいでしょう。
改造者追記：HTML Living Standardでは、hidden属性付き子要素は「無い」ものとして扱って、判定してます。
<APPLET> に ALT 属性と等価な内容の両方を書くことは薦められていません。 *3*
<APPLET> は <OBJECT> と同じように、要素の内容に適当な説明を書くように求められています。しかし、<APPLET> にはALT属性があるので、内容説明に加えてALT属性で説明を書くと、WWWブラウザはどちらを採用していいのかわかりません。つまり、どちらか一方にするように、アクセス指針技術文書4.8.1(J)に書かれています。
<APPLET> は、HTML4.01では薦められないタグであることにも注意してください。
<TAG> の ALT 属性に空白だけの文字列を指定することは薦められていません。 *3*
アクセス指針技術文書5.6.1(J)には、空白だけのALTを指定して、イメージを表示しないときにうまく隙間が空くようにした次のようなのはだめ、と書かれています。
my poem requires a big space<IMG src="10pttab.gif" alt=" ">here
Another HTML-lint では、このような語の途中での指定だけでなく、常にチェックされます。
<TAG> には ALT 属性を指定するようにしましょう。 *4*
イメージが表示できないWWWブラウザも数多く存在します。また、表示ができるWWWブラウザでも、自動的にはイメージを読みに行かないような設定にしてあることもよくあります。そのようなとき、そこにどのようなイメージが貼り付けてあるのか、適切なコメントがあると、表示されたテキストがぐっと読み易くなります。どのようなコメントが適切かは多くの人がいろいろな意見を述べていますが、宗教色の濃い議論もあるので注意が必要です。ここでは、特に指針は示しませんが、空の指定 alt="" も、それなりに有効な場合があることだけは覚えておいてください。WAIの解説(J)を参照してください。
<IMG> 以外でも、この警告は出ますが、ALT属性はHTML4.01ではほとんど必須属性です。
<INPUT type="image"> はイメージのボタンを作ります。ところがこのタグにはALT属性がありませんでした。HTML4.0でようやくALT属性が指定できるようになりました。
この警告は、アクセス性向上のために、WAIで守らなければならない事柄とされています。
改造者追記：HTML Living Standardのimg要素ではALT属性は例外的に省略可能な場合がありますが、必須扱いで判定してます（HTML Living Standard仕様では、文法チェッカーは省略してよい例外にあてはまることが確実でない限りalt属性がなければエラーとして指摘せよ、って感じだし）。
<TAG> には WIDTH と HEIGHT 属性を指定するようにしましょう。 *
イメージのサイズを指定しておくと、WWWブラウザが実際にそのイメージを読みに行かなくても、他のテキスト部分のレイアウトを行なうことができます。これは、ネットワークの負荷を軽減し、迅速な表示が行なえることを意味します。
<INPUT type="image"> はイメージのボタンを作ります。ところがこのタグにはWIDTHやHEIGHT属性がないので、どうしてもイメージの読み込みが起こります。HTML4.01にもありません。
プロバイダ指定の <IMG> を利用するアクセスカウンタCGIなどの中には、イメージの幅が特定できないものもあります。当然そのような場合にはWIDTHを指定することはできません。いや、指定してもいいですが、イメージがゆがむかも知れません。
この警告は減点されません。
<IMG> には ISMAP と USEMAP 属性の両方を指定することはできません。 *3*
ISO/IEC 15445 では、<IMG> にISMAPとUSEMAPの両方を指定してはならないと明記されています。HTML4.01などにこのような記述はないのですが、両方指定するのはおかしいので、どのHTMLでも警告されます。
<IMG ISMAP> でのサーバサイドイメージマップは使わず、クライアントサイドイメージマップを使いましょう。 *4*
サーバサイドイメージマップを使っていると音声出力などでいろいろ不便があったりするため、クライアントサイドイメージマップを利用するようにWAIで強く薦められています。
<TABLE> には SUMMARY 属性を指定するようにしましょう。 *3*
アクセス性向上のために、<TABLE> には、SUMMARY属性を使って要約を付けておくことがWAIで薦められています。
ISO/IEC 15445 では必須属性となっていて、違う警告が出ます。
<TH> には ABBR 属性を指定するようにしましょう。 *3*
アクセス性向上のために、<TH> には、ABBR属性を使ってヘッダラベルの省略形を付けておくことがWAIで薦められています。ただ、もともと省略形の内容の場合など、闇雲にABBRを付けるのは無意味なのですが、そのような識別が Another HTML-lint ではできません。この警告は減点されません。
<COL> を子要素に持つ <COLGROUP> には SPAN 属性を指定すべきではありません。 *3*
HTML4.01(J)には、<COL> を子要素に持つ <COLGROUP> のSPAN属性は無視される、とあります。
ISO/IEC 15445 ではさらに厳しく、禁止されています。
<TAGA> の COLSPAN 属性の指定と、NN行目の <TAGB> の ROWSPAN 属性の指定が重なり合っています。 *5*
<TABLE> のセルの構造で、COLSPAN属性とROWSPAN属性の指定に矛盾した部分があります。HTML4.01(J)にある次の例を見てください。
<TABLE border="1"> <TR><TD>1 <TD>2 <TD>3 <TR><TD>4 <TD rowspan="2">5 <TD>6 <TR><TD colspan="2">7 <TD>9 </TABLE>
"5"のセルと"7"のセルが重なり合っています。
<FRAMESET> タグがありますが、<NOFRAMES> タグがありません。 *3*
フレーム機能をサポートしていないWWWブラウザも多いため、<NOFRAMES> を指定して、そういうWWWブラウザの便宜をはかってあげましょう。<NOFRAMES> を間違ったところに書いていたりスペルミスをしていないかもチェックしましょう。特に、<NOFRAME> と S が抜けていることが多いようです。
とはいえ、<NOFRAMES> があればいいというものでもありません。文法的には非の打ち所がないのですが、
<NOFRAMES> <BODY> <P>このページは Netscape で見て下さい。</P> </BODY> </NOFRAMES>
などというおばかなことはしないようにしましょう。このようにメッセージされても、その人が指示に従えるとは限りません。
<FRAME> の SRC 属性に自分自身を指す URI `XXXX` を指定することはできません。 *5*
HTML4.01(J)によると、<FRAME> の SRC 属性には、自分自身を指すURIを指定することは禁止されています。
<FRAME src="#same_document">
なんて書くことはできません。しかし、
<FRAME src="http://www.uso800.ac.jp/same_document.html">
のような場合は、Another HTML-lint はこれが自分と同じかどうかを判定できません。
<FRAME> の SRC 属性で直接イメージなどを指定することは薦められていません。 *4*
<FRAME SRC> でイメージなどを直接指定することは、WAIでは行なわないようにとされています。アクセス指針技術文書4.10.4(J)は、FRAMEにはHTML文書を、ということなんで、HTML以外を指定することは避けましょう。
この警告は、URIが存在するかどうかチェックしているときのみ有効です。
<FRAME> には TITLE 属性を指定するようにしましょう。 *4*
アクセス性向上のために、<FRAMESET> や <FRAME> には、TITLE属性を必ず書くようにとWAIに書かれています。
改造者追記：アクセス可能な名前（aria-label属性値、aria-labelledby属性値）やaria-describedby属性がある場合は、指摘されません。
<TAG> の ATTR 属性のフレームターゲット名 `XXXX` は NN行目ですでに指定されています。 **
フレームターゲットに同じ名前を付けることはできません。でも、HTML4.01にそのことが書いてあるんでしょうか。
<TAG> の ATTR 属性のフレームターゲット名 `XXXX` は予約されています。 *3*
HTML4.01(J)では、次のフレームターゲット名が予約されています。
このような名前を付けることはできません。というか、一般に付けられる名前の制限はもっときついです。次の警告を見てください。
<TAG> の ATTR 属性のフレームターゲット名 `XXXX` は小文字で書いたほうが安全です。 **
フレームターゲット名の大文字小文字は区別されないことになっています。したがって、
<FRAME target="_top">
と
<FRAME target="_TOP">
は、同じはずなのですが、一部のWWWブラウザは異なるターゲットとみなしてしまいます。予約されているフレームターゲットは小文字で書くようにしましょう。
<TAG> の ATTR 属性のフレームターゲット名 `XXXX` は正しくありません。 *3*
HTML4.01(J)には、フレームターゲット名は英字から始まらなければならない、そうでない名前は無視される、と書かれています。これは、かなり厳しい制約で、将来増えるかも知れない(_topなどの)予約名に対処するためのものだと思われます。しかし、Mozillaなど、HTML4.0に先行してフレームを実装していたWWWブラウザではこのようなことはないようです。
<TAG> は物理的フォントタグです。論理的タグを使うようにしましょう。 *3*
文字フォント修飾のタグには、物理的なものと論理的なものがあります。物理的なものというのは、太字の <B> のように直接的なもので、論理的なものというのは、強調の <EM> という意味的なものです。SGMLの精神からは、なるたけ意味的な表現をするように心がけましょう、といったところなんですが、なかなかそうもいきませんね。WAIでも使わないように薦められています。この警告は減点されません。
顔文字などを <TT>:-)</TT> などと書くことも多いでしょう。このようなのはASCIIアートと呼ばれていて、WAIでは複数行に渡るようなASCIIアートは飛び越せるような工夫が必要とされています。
Laura Lemay のHTML本では、<B> が多用されています。
<P> は段落のためのタグです。改行するタグは <BR> です。 **
<P> を行末に書いているときにこの警告が出ます。<P> は改行するためのタグではありません。<P> を行末に書いていたのは、HTML2.0より前の大昔のことです。RFC1866(J)では段落のためのタグとして、終了タグを伴って定義されています。
かなり多くの参考書が、<P> を改行するためのタグだとか、1行空けるためのタグだとか紹介しています。それは嘘です。そんなことを堂々と書くような著者は信用してはいけません。自分では調べもせず、間違いの書かれた二次文献や三次文献などからの引用で済ませているからだと思われます。
文書構造を無視して整形目的で <BR> を利用しているようなとき、<BR> が頻繁に連続して現れます。この警告を回避するために <BR> <BR> などというお馬鹿なことはくれぐれもしないようにしましょう。
また、Lynxなどの一部のWWWブラウザは、連続する <BR> をひとつにまとめてしまうことがあります。
NN行目の <PRE> 内にはタブを書かないようにしましょう。 *3*
<PRE>～</PRE> 内にタブ文字を書くことは避けるように、HTML4.01(J)で強く要請されています。タブ文字は空白文字に置き換えられて表示されるのが普通ですが、モノによって期待通りの結果を得られないことがあるというのが理由です。つまり、<PRE> の整形済みという主旨に反するということです。
<Hn> が NN行目の <Hm> に続いていますが好ましくありません。 *3*
HTMLには、章や節を直接表現する構造はありませんが、見出し用のタグ <H1>～<H6> が用意されています。本来、これらの出現順序関係については、何の制約もありません。この警告は、<H2> の次に <H4> が来たら何かおかしいんじゃないの、という程度のものですが、このような使い方はRFC1866(J)では推奨されていません。
また、これらを文字サイズ調整の意味に使っていたりするのを防ぐ効果も多少あります。多くの参考書が、<Hn> を文字サイズ調整のタグだと紹介しています。それは嘘です。ついでに、<Hn> は、ヘッダ(header)ではありません。見出し(heading)です。これも参考書がよく間違っています。
この警告は、アクセス性向上のために、WAIで守るべき事柄とされています。
<Hn>～</Hn> 内の <IMG> の ALT 属性には何か説明を書きましょう。 **
見出しにイメージだけが指定されていて、次のようにALT属性が空のときに警告されます。
<H1><IMG src="introduction.png" alt=""></H1>
このようなイメージに対して、<A>の場合はWAIで指摘されているのですが、見出しに対して特に何か言われているわけではありません。しかし、<A>の場合と同じように好ましくないのには変わりないでしょう。
<A> には ACCESSKEY 属性を指定するようにしましょう。 *3*
<INPUT> などに対する同様の警告を見てください。この警告は減点されません。
この警告は <A> に対するもので、他方はそれ以外に対するものです。<A> を別扱いしているのは、WAIでも「重要なリンクに対して
」というただし書きが付いているからで、全部の <A> に対してACCESSKEY属性を要求するものではないからです。Another HTML-lint は、どれが重要なリンクかを判断できません。
アクセス性向上のために、リンクとリンクの間は、何か印字可能な文字(空白でもよい)で区切ることがWAIで薦められています。例えば、
<A href="next.html">次</A><A href="prev.html">前</A>
ではなくて、
<A href="next.html">次</A>|<A href="prev.html">前</A>
とか
<A href="next.html">次</A> <A href="prev.html">前</A>
のようにします。
リンクイメージの <IMG> の ALT 属性には何か説明を書きましょう。 *3*
リンクに使われているイメージで、次のようにALT属性が空のときに警告されます。
<A href="routes.html"><IMG src="topo.gif" alt=""></A>
このようなイメージには、WAIで何か等価な説明を書くようにとされています。
<IMG> の ALT 属性の値 `D` はあまり薦められません。LONGDESC 属性を利用しましょう。 *3*
D-リンクと呼ばれるこの技術は、旧式であまり薦められません。詳しくはアクセス指針技術文書3.2.2(J)や4.7.2(J)を参照してください。
<A> のアンカー `XXXX` は NN行目で異なるリンク先を指しています。 *3*
次のように、同一の内容で異なるリンク先を示すのは、アクセス指針技術文書4.6(J)で好ましくないとされています。
<A href="http://www.everything.org/">なんでもかんでも</A> <A href="http://www.uso800.ac.jp/~k16/everything/">なんでもかんでも</A>
もし、このような必要性に迫られたときは、異なるTITLE属性を付けて区別するように薦められています。
<A href="http://www.everything.org/" title="NANDEMO">なんでもかんでも</A> <A href="http://www.uso800.ac.jp/~k16/everything/" title="KANDEMO">なんでもかんでも</A>
<A> のアンカーとして `ここ` などを使うのは好ましくありません。 *3*
アクセス指針技術文書4.6(J)などによれば、例えば、目の不自由な方がページを読むとき、リンク部分だけを拾って読んだりすることがあるそうです。そのようなとき、
詳しくは<A href="detail.html">ここ</A>をクリックしてね Click <A href="info.html">here</A> for more info.
とかいったリンクでは、意味がわかりません。もっと意味のある文章にしましょう。「ここ」だけじゃなくて「こっちのサイト」とか「このページ」とかいうのも引っかかります。一部の代表的なものしか引っかかりませんが、意図しないものも引っかかってしまうかも知れませんので、そのようなときは k16@chiba.email.ne.jp までお知らせください。
なぜこのようなのがよくないかは、Laura Lemay のHTML入門や、Style Guide for online hypertext(J) などに書いてあります。WAIでもこのような書き方は薦められていません。これは、HERE症候群と呼ばれています。
また、「クリック」というリンクもよくないとされています。なぜなら、リンクをたどる動作はクリックとは限らないからです。「押す」という用言も同様です。
<A> のアンカーとして <IMG> の ALT 属性の値に `ここ` などを使うのは好ましくありません。 **
アンカーに画像を使った場合、画像の内容を表しているALT属性に「ここ」などを指定した場合も HERE症候群とみなします。
<A> のアンカー名 `XXXX` 中に空白文字が含まれています。 *3*
アンカー名にはどんな文字を使ってもいいことになっているのですが、まあ、空白は使わない方がよかろう、ということです。アンカー名に安全でない文字を使った場合も参照してください。
HTML4.01(J)では、どんな文字でも使っていいわけではなくなりました。
<A> のアンカー名 `XXXX` 中に安全でない文字が含まれています。 *3*
アンカー名の扱いは微妙な問題をはらんでいます。アンカー名(fragment ID)の指定は、
<a name="foobar">
として行ないます。NAME属性の値には何を書いてもいいことに注意してください。一方、このアンカーを参照するには、
<a href="http://www.uso800.ac.jp/fake.html#foobar">
あるいは
<a href="#foobar">
のようにURIと一緒に指定します(RFC2396にはこのアンカー名部分はURIの一部ではないと明記されています)。一緒に指定するので、アンカー名にはURIとして正しくない文字は使ってはならない(本当か?)んですが、これは、NAME属性の性質と矛盾しています。URIとして使用できる文字だけで名前を付けているなら何の問題もありません。"[baz]" なんて名前を付けて、"[" や "]" が使えない文字だからといって、
<a href="#%5Bbaz%5D">
としてもうまくいきません。RFCでは、%XXエンコーディングが使えるようなことが書いてあるのですが、ユーザエージェント側に問題があるのかどうか、どうもうまくありません。仮にこのようにエンコードしての表現が正しいとしても、日本語などの名前を付けようと思ったら、とても悲惨なことになります。"はじめに" という名前をJISでエンコードすると
<a href="#%1B$B$O$8$a$K%1B(B">
なんてことになってわけがわかりません。そもそもJISを仮定していいわけがないしね。
というわけで、アンカー名には変な文字や、日本語などは使わない方が安全です。
"%" は、RFC2396では特に例外扱いされていませんが、RFC1738では、アンカー名に使うのは安全でないとされています。
HTML4.01(J)では、アンカー名はASCII文字でなければならないと書いてあります。XHTML1.0(J)では、NAME属性ではなくてID属性でアンカー名を指定するよう薦められており、XHTML1.1では、NAME属性での指定は廃止されました。
アンカー名を指定したつもりが
<a href="http://www.uso800.ac.jp/fake.html#">
となってるときに出る警告です。"#" の後ろの名前がありません。
改造者追記：HTML Living Standardでは、href属性値が「#」の場合は当該文書の先頭に移動することになってますが、これはブラウザ向けの規定であって、HTML文書作成者向けの規定ではありません。よって、容赦なく減点対象とします。
<A> のアンカー名 `XXXX` は NN行目にもありました。 *5*
ひとつのHTML中で同じ名前を何個所にも付けることはできません。
<A name="girl">こばやしちよじ</A> <A name="girl">きくちさよこ</A>
というのは正しくありません。次の警告も見てください。
<A> のアンカー名 `XXXX` は NN行目にもありました。大文字小文字は区別されない可能性があります。 *3*
HTML4.01(J)では、アンカー名は大文字小文字の一致性を要求するものの、次のような例を不正だとしています。
<A name="popie">おりーぶ</A> <A name="POPIE">ぶるーと</A>
ここではID属性については触れていません。ID属性の大文字小文字は、要素名や属性名などが区別されないのと同じ理由で区別されません(SGML宣言(J)の NAMECASE GENERAL YES)。NAME属性の値自身は区別されるので、これらは別々のアンカーとして正当なのですが、NAME属性をやめてID属性にしようという思惑から、あえて指摘しているのだと思われます。
<A> のアンカー名 `XXXX` は NN行目で ID 属性としても指定されています。 *5*
HTML4.01(J)では、<A name>で指定するアンカー名と、いろいろなタグのID属性の値は重複してはいけないことになっています。
<A href="#HAKATA">どげんした</A> <A name="HAKATA">こげんした</A> <H2 id="HAKATA">あげんした</H2>
というのは正しくありません。HTML4.0以上以外では警告されません。
<A> のアンカー名 `XXXX` は NN行目で ID 属性として定義されています。 *
<A href="#HOEE">
に対応するアンカーを、ID属性で指定してもいいことになっています。 つまり、このリンクに
<H1 id="HOEE">
のようなのが対応してもいいのです。しかし、古いWWWブラウザの実装ではこのような対応はあまり実現できていないようです。
XHTML1.0(J)ではNAME属性でなくてID属性を使うように薦められており、XHTML1.1ではそのようなNAME属性は廃止されています。
HTML4.0以外では警告されません。この警告は減点されません。
<A> の NAME 属性の値 `XXXX` と ID 属性の値 `YYYY` は、同一タグ中では同じでなければなりません。 *5*
<A name="HYOEE" id="HYOEE">
のように、同一タグ中でのNAME属性とID属性の値は同じでなければならないとされています。HTML4.0以上以外では警告されません。XHTML1.1では、このようなNAME属性は廃止されています。
<TAG> には NAME 属性と ID 属性の両方を指定するようにしましょう。 *3*
アンカー名の指定は、NAME属性ではなくID属性で行なう方向にW3Cは移行させています。
ISO/IEC 15445 や
XHTML1.0(J)(Appendix C.8)では過渡的な措置として、どちらでもうまくいくように、両方を指定しておくように薦めています。ただし、同じ値を書かなければなりません。過渡的なものなので、XHTML1.1ではそのようなNAME属性は廃止されています。
<TAG> の ID 属性の値 `XXXX` には小文字を含めないようにしましょう。 *3*
ISO/IEC 15445 では、ID属性値には小文字を使わないことが推奨されています。⇒
User's Guide to ISO/IEC 15445:2000(E) ISO-HTML
これは、もともとSGML規格から導出されることなので、ISO-HTMLに限らずHTML4にも言えますが、ISO-HTMLではそのことが明記されているため、ID属性値に小文字を使っただけで警告されます。
SGML宣言の「NAMECASE GENERAL YES」は、単に大文字小文字を同一視せよという意味ではなく、小文字を大文字に変換してから解釈せよという規定です。これは、ID属性値にも適用されるため、HTML4では
<a id="foo">
は
<A ID="FOO">
と解釈されます。しかし、NAME属性値には適用されないので
<a id="foo" name="foo">
は
<A ID="FOO" NAME="foo">
となります。これは、NAME属性値と ID属性値とを同じにせよという規定に反しています。 HTML4ではこのような場合に ID属性に小文字が含まれていると警告されます。 また、小文字の ID属性値に対して HREFでリンクされているときも警告されます。ここで注意しなければならないのは、
<a id="foo">
を参照するには
<a href="#FOO">
としなければならないということです。しかし、実際にこのようなSGML的に正しい挙動をするWWWブラウザがどの程度存在するのか、わたしは知りません。たいていは、小文字のフラグメントIDで動作するものと思われます。これは、利用者からは何の違和感もありません。
XHTMLでは、大文字小文字が区別されるのでこのような問題は発生しませんが、XHTMLからHTML内のIDを参照する場合は、そのID値は大文字に変換されるため、大文字で参照する必要があります。
<A> のアンカー名 `XXXX` が見つかりませんでした。 *3*
リンクを
<A href="#shit">
と書いたとき、このアンカーはそのHTML中に存在しなければならないのですが、これが見つからないときに警告されます。名前は大文字小文字が区別されるので注意してください。
改造者追記：HTML Living Standardでは、#topの参照先が見つからない場合は当該文書の先頭に移動することになってますが、これはブラウザ向けの規定であって、HTML文書作成者向けの規定ではありません。よって、#topの参照先が見つからない場合は容赦なく減点対象とします。
<A> のアンカー名 `XXXX` は参照されていません。 *
指定されているアンカー名が同一のHTML中で参照されていないからといって、それが誤りとはいえません。ただ名前を付けているだけかも知れませんし、別のHTMLから参照されているかも知れないからです。しかし、名前の大文字小文字を間違っていたり、スペルミスなどがないとはいえません。この警告は減点されません。
つまり、
<IMG src="">
なんて書くのはちょっと、ということなんですが、RFC1808によると、URIが空の場合は <BASE> で指定されているURIと同じとみなすように書かれています。<BASE> がないときは自分自身と同じなので、そのとき
<A href="">
とした場合は、自分自身にリンクしていることになるのですが、Mozillaなどではそのような効果を期待することはできないようです。それどころか、JavaScriptとの組み合わせで、
<A href="" onClick="this.href=pickupRandomURL()" onMouseOver=...>
なんていうサンプルまであります。
<TAG> の ATTR 属性の URI `XXXX` 中に空白文字が含まれています。 *3*
URIに空白を含めることは禁止されていませんが、安全ではありません。URI中では空白は %20 として表現します。
<TAG> の ATTR 属性の URI `XXXX` 中に `\` が含まれています。パスの区切りは `/` でなければなりません。 **
URIではディレクトリ階層を示す区切りは "/" です。Windowsなどの "\" は "/" に置き換えましょう。
<TAG> の ATTR 属性の URI `XXXX` 中に `~` が含まれています。%7E と書いた方が安全です。 *
1998年8月にRFC1738とRFC1808を統合してURIの一般構文を定めたRFC2396が標準化されました。これ以前は、URIとして "~" (チルダ) は安全でない文字とされていましたが、RFC2396では晴れて使える文字となりました。この "~" は、アカウント名のプレフィクスとして "http://www.uso800.ac.jp/~k16/" のようによく使用されます。気になるなら、"http://www.uso800.ac.jp/%7Ek16/" と書いた方がいいでしょう。
RFC2396でも、チルダは異なる文字(字形)として入力されることが多いのにもかかわらず、みんなが使うもんだからしょうがなく使えるようにしたことが窺がえます。実際、Shift_JISには半角のチルダは含まれておらず、上線(￣)となっています。
この警告は、以前のようにチェックできるようにするもので、減点されません。
<TAG> の ATTR 属性の URI `XXXX` 中に使用できない文字 `X` が含まれています。%XX と書かなければなりません。 *3*
一般の URI (Uniform Resource Identifier) は、RFC2396で規定されています。ASCII コード 20～7E 以外の文字に対しては、別の警告が出ます。しかし、ASCII文字の中にも使用を除外されている文字がこのRFCに示されています。以下の文字が、除外されています。これらのうち、空白と "\" は別の警告が出ますし、http: スキームのときは "#" はアンカー名の区切りに解釈されます。
| 空白 | %20 | |
" | %22 | |
# | %23 | |
% | %25 | |
< | %3C | |
> | %3E | |
[ | %5B | |
\ | %5C | |
] | %5D | |
^ | %5E | |
` | %60 | |
{ | %7B | |
| | %7C | |
} | %7D |
これらは、ASCIIコードを、右に示してある % に続く 2桁の 16進数(大文字でも小文字でも同じ)で表現します。
プロバイダ指定のCGIの中には "|" をそのまま書くように指定してあるものもあります。この場合、これを %7C にして動作しないのは、そのCGIが正しい仕様を守っていないからなので、諦めてください。
これらの文字は、RFC1738では安全でない(unsafe)とされていましたが、RFC2396では除外(excluded)とされています。
次のようなCGI呼び出しは、Muhammad A Muquit氏の WWW Homepage Access Counter and Clock です。
Count.cgi?df=hogehoge.dat|dd=A|frgb=FFFF00
この有名なアクセスカウンタは、区切りには "|" か "&" を指定できるので、"&" を指定した方がいいでしょう。このとき、HTML中では "&" と書きます (これについては不明な実体参照を参照のこと)。
Count.cgi?df=hogehoge.dat&dd=A&frgb=FFFF00
なお、このCGIの仕様書のキーワード一覧の degrees のところに、MSIEでは °rees が度文字に解釈されてしまって、これはMSIEのバグだ
、と書かれていますが、これはまったくの濡れ衣です。実体参照として ° がMSIEに限らずHTML4.01などで定義されていて、これを解釈するWWWブラウザなら度文字が表示されるかも知れないからです(細かいことを言えば、; がないので実体の終わりがわからず、適当に評価されるかも知れないということ)。&degrees と書かない方が悪いのです。さらに具合の悪いことに、degrees は危ないけど代替の angle なら安全だ、などと書かれていますが、∠ という実体参照も定義されているので、ちっとも安全ではありません。ついでに、ℑ、≠ という実体参照もキーワードと競合します。いずれにしても、パラメタ区切りを "&" のまま書くからいけないので、"&" と書けばどんな場合も安全です。
<TAG> の ATTR 属性の URI 中の実体参照 `&xx;` は使用できない文字 `X` です。 *3*
URI中に実体参照を用いて
<A href="<where>">
なんて書いても、これは "<where>" と書いたのと等価です。つまり、< や > などはURIに使えない文字なので、< や > などもURIには使えません。どうしても < や > などを書きたければ、
<A href="%3Cwhere%3E">
のようにします。&image のように、CGI呼び出し中の & に続くパラメタが、たまたま定義されている実体参照と同じだった場合にもこの警告が出ることがあります。CGI呼び出し中のパラメタ区切りは & と書くようにしましょう。
ÿ のような文字参照も同様です。このとき、含まれる # はアンカー名との区切り文字とはみなされません。
<TAG> の ATTR 属性の URI `XXXX` 中に ASCII以外の文字が含まれています。 *5*
URIに使用できる文字は、ASCII コード 20～7E の文字だけです。漢字やカタカナなどは使用できません。
改造者追記：国際化ドメインでは使用はできると思われますが、この改造版では対応してません。
改造者追記：属性値がIRIのものは、URIで代用して判定してるので、このエラーが出ることがあります。
<TAG> の ATTR 属性の URI に指定されているスキーム名 `XXXX` は正しくありません。 *5*
URIに指定できるスキーム名は、英小文字、数字、プラス "+"、ピリオド "."、ハイフン "-" から成る、とRFC2396に書いてあります。英大文字についてはそれを小文字とみなしてもよいとも書いてあります。この警告は、これらに違反したときに出ます。
<TAG> の ATTR 属性の URI のスキーム名 `XXXX` は小文字で指定しましょう。 **
URIに指定するスキーム名に使える文字には、本当は英大文字は含まれていませんが、RFC2396では、大文字を小文字とみなすような融通を利かしてもよいと書いてあります。
<TAG> の ATTR 属性の URI に不明のスキーム名 `XXXX` が指定されています。 **
URIに指定できるスキームに何があるのかをすべて把握しているわけではありません。いくつかのRFCにあるものなどを拾ってありますが、これらに含まれないスキーム名のときこの警告が出ます。もし、正しいのに警告されるときは k16@chiba.email.ne.jp までお知らせください。でも、多くはスペルミスです。
RFC1738にあるのは以下のとおりです。
http:
ftp:
file:
gopher:
mailto:
news:
nntp:
telnet:
wais:
prospero:
また、セキュリティサーバのための https: などはRFCにはありませんし(たぶん)、HTMLで使って有意かどうかは別にして、他のRFCにもさまざまなスキームが定義されていますが、ここでの紹介は割愛します。
Mozillaなどでは、さらに
view-source:
javascript: / livescript: / mocha:
about:
montulli:
といったスキームも使用できます。これらのMozilla特有のスキームについては、Netscape Tips&Tricks などを見てください。
改造者追記：属性値がIRIのものは、URIで代用して判定してるので、このエラーが出ることがあります。
<TAG> の ATTR 属性の URI `XXXX` はインタネット上から参照できないかも知れません。 **
インタネット上に公開するHTML中のURIに、file: などのローカルファイルを指すスキームを指定しても、そのファイルを参照することはできません。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
<TAG> の ATTR 属性の URI のスキーム `XXXX` は利用できません。 *3*
TTNet ドットi では、利用できるスキームは http: mailto: tel: だけです。
<TAG> の ATTR 属性の URI に指定されているスキーム `javascript` の利用は薦められていません。 *3*
URIに"javascript"を使うのは、利用者がスクリプトを使わない環境のときなどのことを考えて、使用を慎むように、アクセス指針技術文書4.12.1(J)に書かれています。しかし、実際には必ずしも制限される必要のない javascript スキームも少なからず存在します。例えば、javascript が動作すれば恩恵を被るものの、動作しなくてもなんら支障のないような場合などです。この警告は減点されません。
<TAG> の ATTR 属性の URI `XXXX` は正しくない書式です。 *3*
URIの格好はRFC2396で決められていますが、これは総括的な一般URIの構文を規定しているだけで、個々のスキームごとの構文を規定しているわけではありません。ここでは、RFC1738などで決められている次のスキームについて個別のチェックを行ないます。このチェックに違反するとこの警告が出ます。
http://host[:port]/path[?query][#fragment-id]
ftp://[user[:passwd]@]host[:port]/path
file://[[user[:passwd]@]host[:port]]/path
gopher://host[:port][/type[selector[%09query[%09string]]]]
mailto:user@domain[?name=value]
news:[article@]domain
nntp://host[:port]/newsgroup[/article]
telnet://[user[:passwd]@]host[:port][/]
wais://host[:port]/[database]
prospero://host[:port]/path[field]
ただし、上記構文はかなり端折ってあり、正確ではありません。本当はそれぞれもっといろいろな書き方があります。正確な構文等を知りたいときは以下を参照してください。ただし、Another HTML-lint ではRFC1738以外が必ずしも反映されているわけではありません。また、RFC2396には、これらの修正情報があります。
個々のスキームごとに使用できる文字が微妙に異なっていますが、URIで表記するときにRFC2396で禁じられている文字を、直接書いたり実体参照などを用いて表現したりすることはできません。このような文字は、すべて %3C のように表現しなければなりません。
いくつか間違った例を示しましょう。
http:~k16/hogehoge.htmlhttp:/~k16/hogehoge.html
http: などのスキーム名を付けることはできません。http: は付けないようにします。
http://.uso800.ac.jp/~k16/hogehoge.html
. から始まることはありません。
http://fake_univ.uso800.ac.jp/~k16/hogehoge.html
http://bogus-.uso800.ac.jp/~k16/hogehoge.html
http://geregere:password@uso800.ac.jp/~k16/hogehoge.html
http: にユーザIDやパスワードを含めることはできないことになっています。しかし、一部のユーザエージェントはこれを受け付けています。安全のためには、URI中に素のパスワードなどは書かないようにしましょう。ftp: などには構文上含められます。
http://www.uso800.ac.jp/cgi-bin/hogehoge.cgi?foo=bar|zoo=penguin
| が用いられています。| はURIに使えない文字なので %7C と表記しなければならないのですが、残念ながら、そうすると動作しないCGIが多数存在します。Muquit氏のアクセスカウンタ (Count.cgi) に関してURIに使えない文字の解説を見てください。
http: //www.uso800.ac.jp/
file://c:/homepage/index.htmlfile://c:\homepage\index.html
localhost とするか空にする必要があります。また、WindowsやDOSのディレクトリ区切り \ は使えないので / に置き換えます。Macintoshのディレクトリ区切り : も / に置き換えます。file://localhost/c:/homepage/index.htmlfile:///c:/homepage/index.html
: を | に置き換えることもあるようです(これの出典はどこですか? k16@chiba.email.ne.jp までお教えください)。しかし | はURIに使えない文字なので %7C と表記します。
file:///c%7C/homepage/index.html
mailto:geregere.uso800.ac.jp
@ です。
mailto:geregere@uso800.ac.jp
mailto:ｇｅｒｅｇｅｒｅ＠ｕｓｏ８００．ａｃ．ｊｐ
mailto:Killer Panther <geregere@uso800.ac.jp>
mailto:Killer%20Panther%20%3Cgeregere@uso800.ac.jp%3E
mailto:いしの <k16@uso800.ac.jp>
mailto: は、他の(http:などの)スキームと異なり、直ちにこのURIによってメールが送信されたりすることはありません。WWWブラウザがこのURIの情報を解釈してメーラに渡し、メーラを利用者が操作して(本文などを書いてから)メールを送信することになります。このため、mailto: URIの書式にはかなり自由度のある実装がされていると思われます。mailto:k16 @ uso800 . ac . jp
news://news.uso800.ac.jp/uso800.www.authoring
nntp: の構文です。多くのユーザエージェントはこれを news: として受け入れているようです。現在のRFC的には news: として正しい構文とはいえませんが、許容される方向にあるようです。
news:123/news.uso800.ac.jp
/ は含まれません。これはきっと news:123@news.uso800.ac.jp の間違いです。
news:123@.news.uso800.ac.jpnews:uso800@192.168.0.1
本来の目的とは無関係に、mailto: などの後ろに文章を書くという裏技(?)が存在するようです。これは、Mozillaなどでマウスを持って行くとステータスラインにその文章が表示されるという効果を狙ったものだと思われます。
改造者追記：国際化ドメインでは全角文字や日本語等の文字も使用できる思われますが、この改造版では対応してません。
改造者追記：属性値がIRIのものは、URIで代用して判定してるので、このエラーが出ることがあります。
<TAG> の ATTR 属性の URI `XXXX` は `/` で終わらせるようにしましょう。 **
URIで指定できるスキームには、http、ftp、mailto などいろいろありますが、http/https スキームについてだけ調べています。http スキームのURIは、
http://host:port/path
みたいな構文です。多くのサーバでは、デフォルトHTMLは省略できるので、
http://www.uso800.ac.jp/fake/index.html
を
http://www.uso800.ac.jp/fake/
と省略することができます(デフォルトHTMLがindex.htmlの場合)。これを
http://www.uso800.ac.jp/fake
と書いてしまうと、fake というファイルを探しに行ってみたら、実はそれはディレクトリだった、ということで、改めて index.html なりを探しに行くので、むだが多く、好ましくありません。だから、ディレクトリを示すURIには "/" を付けなければなりません。しかし、実際にそのURIが存在するかどうかは、(指定されたとき以外は)Another HTML-lintでは調べていないので、このような場合の警告を出すことができません。ここでは
http://www.uso800.ac.jp/%7Ek16 http://www.uso800.ac.jp/~k16
というような場合にだけ警告が出ます。アカウント名のプレフィクスは、指定で ~ 以外にもなるんだけど、まあ、多くは ~ だろうということです。
URIが存在するかどうかチェックしているときには、実際に "/" が必要かどうかがチェックされることがあります。現在はURI取得の方法にLWPを使った環境でのみ可能です。
また、
http://www.uso800.ac.jp
というのは誤りではありません。このホスト名の指定だけの場合は "/" を省略してもいいことになっています(RFC1738、RFC1808)。
<TAG> の ATTR 属性の URI `XXXX` はうまく評価されないかも知れません。 **
// で始まるURIは、正しいURIです。しかし、これはWWWブラウザによっては正しく評価されないかも知れません。
改造者追記：無減点に変更。
<TAG> の ATTR 属性の URI `XXXX` は NN行目で `YYYY` と指定されています。 *
例えば、
http://www.uso800.ac.jp/bogus/
というURIと、
http://www.uso800.ac.jp/bogus
というURIが指定されている場合、"/" のある方とない方とどちらかが間違いなのが明白です。この警告はこのようなとき出ます。http/https スキームについてだけ調べています。
なーんて、浅知恵で考えていましたが、実際には "/" のありなしでまったく異なるリソースを指すことが可能です。例えば、
http://www.perl.com/CPAN/ http://www.perl.com/CPAN
のような実例があります(注意: 2004/12現在、上は同じリソースを指すようになっています)。 とは言っても、そのような設定をされているサーバがそんなに多いとも思えないので、この警告自身は残しておきますが、減点されません。
<TAG> の ATTR 属性の URI `XXXX` は NN行目で `YYYY` と指定されています。 *
index.html の多くはデフォルトHTMLであろう、という仮定で、同一HTML中に
http://www.uso800.ac.jp/fake/index.html
と
http://www.uso800.ac.jp/fake/
などが混在しているときに警告されます。WWWブラウザは、これらが同じリソースかどうかを判断できないので、別々にキャッシュしてしまい、効率的でありません。http/https スキームについてだけ調べています。
また、こんなことはしないとは思いますが、
http://www.uso800.ac.jp/bogus/fake/../index.html
と
http://www.uso800.ac.jp/bogus/index.html
は同じリソースを指すとみなしています。こんなことはしないと思っていたら、(同じリソースを指すという前提で)存外にすることがあるようです。
<BASE> の HREF 属性で指定するより前に NN行目で相対 URI が指定されています。 *5*
<BASE> でHREF属性を指定するときは、それより前に相対URIを用いて外部との関連付けを行なってはなりません。
HTML4.01(J)では、一切の参照を制限しています。HTMLかどうかなど、リソースの種類についての限定は行なっていないことに注意してください。しかし一方で、<BASE> は相対URIに対してのみ効果のあることも書かれています。Another HTML-lint では、<BASE> 以前に出現する相対URIについてのみ警告します。
<BASE> の HREF 属性の URI は絶対位置で指定しなければなりません。 *5*
<BASE> のHREF属性で指定するURIは、絶対指定でなければならないことが、HTML4.01(J)に書かれています。つまり、
<BASE href="base.html">
などとすることはできません。
<BASE href="http://www.uso800.ac.jp/bogus/fake/base.html">
のようにする必要があります。
HTMLは </HTML> が現れたらおしまいです。WWWブラウザによっては </HTML> の後も表示しますが、そんなのを期待してはいけません。
XXXXXX では、HTML文書は NKバイト以内でなければなりません。 *5*
NTT DoCoMo の iモード用のHTML文書は2Kバイト(2.0では5Kバイト)以内に、J-SkyWeb用のHTML文書は6Kバイト以内に、それぞれ収めなければなりません。このバイトサイズには、ページ中で使用されているイメージファイルのサイズも含まれるのですが、通常はそこまでは加算してのチェックはされません。URIが存在するかどうかチェックしているときには加算されます。
<IMG> の SRC 属性の URI `XXXX` が YYY ではありません。 *5*
NTT DoCoMo の iモード用のHTML文書に利用できるイメージはGIFのみです。さらに iモード 1.0 では２階調GIFのみの対応なのですが、調べたGIFが２階調かどうかはチェックされません。
また、J-SkyWeb用のHTML文書に利用できるイメージはPNGのみです。
この警告は、URIが存在するかどうかチェックしているときのみ有効です。
<TAG> の入れ子が深過ぎます。<UL>、<OL> の入れ子は 3階層以内でなければなりません。 *5*
J-SkyWeb用のHTMLでは、<UL>、<OL> の入れ子は 3階層までしか許されていません。
<TAGA> 中に指定できる <TAGB> は NN個までです。 *5*
J-SkyWeb用のHTMLでは、<UL>、<OL> 内に書ける <LI> は 99個までしか許されていません。
NTT DoCoMo の iモード 4.0用のHTMLでは、<OBJECT> 内に書ける <PARAM> は 16個までしか許されていません。
XXXXXX は <HTML> から始まらなければなりません。 *5*
変な決まりですが、特許出願用文書の先頭は <HTML> でなければなりません。
XXXXXX は Shift JIS で記述しなければなりません。 *5*
特許出願用文書は Shift JIS で書かなければならない決まりです。また、NTT DoCoMo の iモード 用のときも Shift JIS で書かなければなりません。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
XXXXXX では `■` を使うことはできません。 *5*
特許出願用HTMLに使える文字については、くどくどいろいろ細かい決まりがあるのですが、とりあえず、利用者使用禁止となっている文字だけチェックしています。また、使える文字として半角カタカナや、丸付き数字の一部などが追加されています。
空要素タグを閉じるスラッシュの有無を統一するようにしましょう。 *
改造者による追加オプション。
HTML Living StandardのHTML構文ではどちらでも書けますが、統一した方がよろしかろうという宗教的な警告です。
HTML Living StandardのXML構文ではきちんと閉じなければいけません。
<TAG> のTARGETの属性値 `_blank` は、あまり薦められない値です。別窓を開く場合は、事前に警告しましょう。 *3*
改造者による追加オプション。
WAIでは「無断で新しいウィンドウを表示したり、現在のウィンドウを変更したりしない」とされてます。
事前警告の有無が判定できないので、減点数は低めです。
セクショニング要素に比べて見出し要素が少ないです。見出しがないセクションがある可能性があります。 *5*
改造者による追加オプション。
セクショニング要素（SECTION、ARTICLE、NAV、ASIDE）の個数にBODY要素分１を加えた個数と、見出し要素（Hx要素）の個数とを比べて、見出し要素の個数が少ない場合に警告されます。
BODYタグが省略されていると、チェック漏れや判定ミスをする可能性があります。
XXXXXXてますが、外部にXXXファイルを用意した方がいいかもしれません。 *
改造者による追加オプション。
構造(HTML)と見た目(スタイルシート)と動き(スクリプト)の分離を推奨するオプションです。
STYLE要素、STYLE属性もしくはonxxx属性の使用、またはSCRIPTタグ内へのスクリプト文の埋め込みがあると警告されます。減点されません。
ジャバスクリプトではイベントを捉えるのもスクリプト内で可能ですので、onxxx属性を使わないことができます。
改造者による追加オプション。
文字通りです。
見た目を確保するためだけに全角空白を使用している場合から、単なるコーディングミスまで、さまざまなパターンが考えられます。
日本語の文章において、段落の行頭の一文字分の字下げを、全角空白とするか、スタイルシートのインデントで調整するかについては、賛否両論あるところでしょう（欧米流のインデントと解釈すべきか、日本標準語の文法上一文字分の空白だと解釈すべきか）。
改造者による追加オプション。
文字通りです。
特にHTML Living Standardの仕様では、BR要素が使われるのはきわめて例外的な場合に限られるような書き方がされてます。
段落はP要素で表せられます。整形済みテキストならばPRE要素を使用する方が適切です。リストタイプの列挙事項はUL要素・OL要素の使用が適切です。見た目を整えるためならば、スタイルシートを使用しましょう。
<TAG>があります。HTML Living Standard仕様に沿ったマークアップかどうか確認しましょう。 *
改造者による追加オプション。
旧物理フォントタグ等（B,HR,I,S,SMALL,U）があったら指摘されます。
HTML Living Standardの仕様では論理要素に変更されてますので、HTML4等から移行した場合などには、HTML Living Standard仕様に沿ったマークアップかどうか今一度確認しましょう。
ATTR属性がありますが、Another HTML-lint では正確な評価はできません。
改造者による追加項目。
WAI-ARIAのrole属性、aria-xxx属性については、Another HTML-lintでは、正確な評価はできません。
Nu Html Checkerでのチェックをお薦めします。
RDFa関連属性については、Another HTML-lintでは、正確な評価はできません（属性値のチェックすら実質やってません）。
itemscope属性を使うときは、ietemtype属性も指定しましょう。 **
改造者による追加項目。
必須とはされてませんが、itemtype属性がないと、検索エンジン等のユーザーエージェントにどのような意味をもつmicrodataなのか理解してもらえない可能性が高いです。
ATTR属性を指定するときは、itemscope属性を指定しなければなりません。 *6*
改造者による追加項目。
itemscope属性がない要素に、itemtype属性、itemid属性、itemref属性を指定することはできません。
itemid属性を指定するときは、itemtype属性も指定しなければなりません。 *6*
改造者による追加項目。
itemid属性を指定するときは、itemtype属性も必須です。
itemprop属性がありますが、 いずれのitemscope属性付き要素にも関連づけられていません。 *6*
改造者による追加項目。
関連付けの方法は以下の二つです。
itemprop属性付き要素を、itemscope属性付き要素の子孫要素とする方法。
itemscope属性付き要素にitemref属性を指定し、そのitemref属性値にスペース区切りで、itemprop属性付き要素のidを指定する方法（itemprop属性付き要素の祖先要素のidを指定することも可能）。
itemref属性による関連付けについて、一部とらえきれないパターンがあるので、正しいのにエラーが出ることがあります（itemref属性値のターゲットのid属性値を指定した要素がitemref属性値付き要素の前方に配置されており、当該id属性値指定要素の子孫要素にitemprop属性があるパターン）。
同一文書（DIALOG要素内を除く）又は同一DIALOG要素内にautofocus属性を複数指定することはできません。これ以前の行にもありました。 *6*
改造者による追加項目。
同一文書内（DIALOG要素内を除く）にautofocus属性を複数指定することはできません。
同一DIALOG要素内にautofocus属性を複数指定することはできません。
文字コードがUTF-8以外のようですが、XHTMLではUTF-8が推奨されます。HTML Living Standardでは、UTF-8でなければなりません。 *3*
改造者による追加項目。
XHTMLはXMLでもあります。すべてのXML processorsは、UTF-8またはUTF-16を扱えることが必須とされてます。逆にいうと、これら以外の文字コードを扱えないものが存在する可能性も否定はできません。
HTML Living Standardでは、UTF-8でなければなりません。
boolean属性の省略表記と非省略表記を統一するようにしましょう。 *
改造者による追加オプション。
HTML Living StandardのHTML構文では、boolean属性は値指定のchecked="checked"（HTML Living Standardでは、checked=""も可）と省略表記のcheckedのどちらでも書けますが、統一した方がよろしかろうという宗教的な警告です。
HTML Living StandardのXML構文では値指定が必須です。
draggable属性を使うときは、title属性も指定しましょう。 *4*
改造者による追加項目。
HTML Living Standard仕様では、非視覚系ブラウザ等向けにtitle属性で説明を入れるべき（should）とされてます。
H1要素が複数あります。 **
改造者による追加項目。
普通の文書であれば、最上位の見出しが二つ以上あることは想定しがたいです。
XX要素のXX属性値がXX属性値より大きいor小さいです。 *6*
改造者による追加項目。
要素によっては、minとかmaxとかいう属性があり、大小関係が規定されてます。
<TAG>は、暗黙の段落の境界をまたいでいる可能性があります。 *
改造者による追加オプション。
厳密にはチェックしてません。
チェック対象は、HTML Living StandardのA,DEL,INS,MAP要素です。
簡便な判定方法として、当該要素直下に「テキスト」とおおむね「Phrasing contentではなく、かつ、Embedded contentではなく、かつ、Flow contentであり、かつ、空要素ではない要素」とが混在している場合に、指摘が入ります。
<TAG>内で、段落の重なり合いがある可能性があります。 *
改造者による追加オプション。
厳密にはチェックしてません。
チェック対象は、HTML Living StandardのBODY要素と、HTML Living Standardのおおむね「Phrasing contentではなく、かつ、Embedded contentではなく、かつ、Flow contentであり、かつ、空要素ではなく、かつ、内容モデルにFlow contentを含む要素」
簡便な判定方法として、当該要素直下に「テキスト」と「AUDIO,CANVAS,OBJECT,VIDEO要素」とが隣接して入っていると指摘が入ります。
<TAG>を使うときは、その内容に<track>を含めましょう。 *4*
改造者による追加項目。
メディア要素を使うときは、アクセシビリティの観点から、何らかの方法で当該メディアの表現内容にかかるテキスト情報を提供することが推奨されてます。
track要素の使用はその方法の一つとなります。
文書の最初の見出し要素が、トップレベルではありません。 **
改造者による追加項目。
HTML文書を最初から順番にたどっていったときに最初に出てくる見出し要素が、「H1要素」ではない場合に、指摘されます。
文書の最初に出てくる見出し要素はトップレベルであるのが普通だよね、という話。
文書に見出し要素が一切ない場合にもこの警告が出ます。
<TAG>の見出しレベルが、セクションの階層レベルと一致してません。 **
改造者による追加項目。
H1-H6要素の見出しレベル（要素名の数字）と、「当該要素の祖先セクショニング要素（SECTION、ARTICLE、NAV、ASIDE）の数 ＋ １」が一致しない場合に指摘されます。
祖先にセクショニング要素がない場合は、チェックしません。
セクショニング要素でセクションを階層化している場合に、見出し階層レベルとセクション階層レベルの完全一致を促し、かつ、暗黙セクションを明示セクション化するように促す警告となります。
改造者による追加項目。
ボタン以外のフォーム部品にlabel要素によるラベルが付されていない場合に指摘されます。
アクセス可能な名前（aria-label属性値、aria-labelledby属性値、title属性値）やaria-describedby属性がある場合は、指摘されません。