- 文法的に間違っているもの。 *6*
- 文法的には正しいが、HTMLとして正しくないもの。 *6*
- 文法的にもHTMLとしても正しいが、 WAIやテクニカルノートなどで守らなければならない (優先度1) とされているもの。 *4*
- 文法的にもHTMLとしても正しいが、WAIやテクニカルノートやRFCで推奨されていないもの。 *3*
- 経験的によろしくないんじゃないかとされるもの。**
- 宗教的によろしくないんじゃないかとされるもの。 *
- プログラムの都合によるもの。
0. エラーの数が 999個を超えたのでチェックを打ち切ります。
あまりエラーが多いときは、チェックを打ち切るようにしています。打ち切られた行以降の文書には、もしかしたら重要なエラーが含まれているかも知れませんが、チェックされません。同じようなエラーばかり出ているときは、そのエラーをチェックしないようにしてみてから、もう一度チェックしてみるといいでしょう。 もしも、同じ行の同じエラーがずっと繰り返されている場合は、プログラムの不具合だと思われますので、是非support@heartcore.co.jp までお知らせください。
1. <TAG> の ATTR 属性の URI `XXXX` はインタネット上に存在しないかアクセスできません。 **
指定されているURIが実際に存在するのかチェックしますが、処理の迅速化のためにタイムアウトの時間はかなり短く設定されています(変更可)。それでも、サーバの反応が遅いリンクが多い場合は時間がかかるでしょう。http: スキームのみチェックしています。ただし、正しくないURIのときはチェックしません。
メッセージの後に数字が付いている場合、それは、HTTPリクエストの結果のコードです。このコードは大きく分けて次のように分類されています。
| 100番台 | 通知 | |
| 200番台 | 成功 | |
| 300番台 | 移転 | |
| 400番台 | クライアントエラー | |
| 500番台 | サーバエラー | |
これらのうち、このチェックで返ってくる可能性のあるコードでエラーとなるのは 400番以降のときです。しかし、確実にリソースが存在しないかアクセスできないのは次の場合くらいです。
| 403 | アクセス権がない | |
| 404 | ファイルが存在しない | |
| 410 | サーバから削除された | |
認証が必要なもの(401)などはそのリソースが存在することは明らかですし、サーバエラーのときは存在するのかしないのかは不明です。Another HTML-lint 5 ではこのようなリソースの文法チェックをすることはできません。
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に対して存在しないなどとエラーになりますのでご注意ください。
2. 最初の記述が DOCTYPE宣言ではありません。 *3*
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 5 ではHTML以外は想定していません。
3. DOCTYPE宣言の前に何か制御文字が含まれています。 **
DOCTYPE宣言の前に、何か制御文字が含まれています。これは、JISのエスケープコードなど、不可視かも知れません。バイナリダンプなどでの調査が必要かも知れません。
4. 不明な DOCTYPE宣言です。
現在 Another HTML-lint 5 がサポートしているDOCTYPEは以下のとおりです。文法はそれぞれのタグ一覧を表示します。言い訳ですが、規則ファイルから動的に生成しているため、あまり親切な一覧ではありません。なお、以下「DOCTYPEはありません」と書いてあるのは、公開識別子がないという意味です。
DOCTYPE宣言の意味については、文書タイプ宣言の意味などを見てください。特に、宣言末の "EN" というのは、宣言されているDTDが英語で書かれているという意味で、そのHTML文書がどうこういう意味ではありません。勝手に "JA" などに書き換えてはいけません。
また、HTML4.0がHTML3.2の上位互換などということはありません。ほとんどのHTMLにはこのような互換性はありません。
XHTMLでは、DOCTYPE宣言内にシステム識別子が必要です。
- HTML1.0 → 文法
HTML1.0用のDOCTYPEはありません。 - HTML2.0(RFC1866) (J) → 文法
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> - HTML2.x(RFC2070) (J) → 文法
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN"> - HTML+ → 文法
<!DOCTYPE HTMLPLUS SYSTEM "HTMLPLUS.DTD"> - HTML3.0 → 文法
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN"> - HTML3.2 (J) → 文法
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> - HTML4.0 Strict (J) → 文法
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> - HTML4.0 Transitional (J) → 文法
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> - HTML4.0 Frameset (J) → 文法
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"> - HTML4.0 Mobile (J) → 文法
<!DOCTYPE HTML SYSTEM "html40-mobile.dtd"> - HTML4.01 Strict (J) → 文法
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> - HTML4.01 Transitional (J) → 文法
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> - HTML4.01 Frameset (J) → 文法
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"> - XHTML1.0 Strict (J) → 文法
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - XHTML1.0 Transitional (J) → 文法
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> - XHTML1.0 Frameset (J) → 文法
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"> - XHTML1.1 → 文法
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> - XHTML + RDFa 1.0 → 文法
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> - XHTML Basic (J) → 文法
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> - XHTML Mobile Profile → 文法
<!DOCTYPE html PUBLIC "-//OPENWAVE//DTD XHTML Mobile 1.0//EN" "http://www.openwave.com/DTD/xhtml-mobile10.dtd"> - ISO/IEC 15445 → 文法
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HyperText Markup Language//EN">
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HTML//EN"> - ISO/IEC 15445 Preparation → 文法
<!DOCTYPE Pre-HTML PUBLIC "ISO/IEC 15445:2000//DTD HyperText Markup Language//EN">
<!DOCTYPE Pre-HTML PUBLIC "ISO/IEC 15445:2000//DTD HTML//EN"> - Netscape Navigator 2.0 → 文法
- Netscape Navigator 3.0 → 文法
- Netscape Navigator 4.0 → 文法
Netscape Navigator(Mozilla)用のDOCTYPEはありません。 - Microsoft Internet Explorer 3.0 beta → 文法
<!DOCTYPE HTML PUBLIC "-//Microsoft//DTD Internet Explorer 3.0 HTML//EN"> - Microsoft Internet Explorer 3.0 → 文法
- Microsoft Internet Explorer 4.0 → 文法
- Microsoft Internet Explorer 5.0 → 文法
- Microsoft Internet Explorer 5.5 → 文法
MSIE用のDOCTYPEはありません。 - IBM WebExplorer 1.1 → 文法
WebExplorer用のDOCTYPEはありません。 - Compact HTML → 文法
<!DOCTYPE HTML PUBLIC "-//W3C//DTD Compact HTML 1.0 Draft//EN"> - NTT DoCoMo iモード 1.0 → 文法
- NTT DoCoMo iモード 2.0 → 文法
- NTT DoCoMo iモード 3.0 → 文法
- NTT DoCoMo iモード 4.0 → 文法
- NTT DoCoMo iモード 5.0 → 文法
NTT DoCoMo iモード用のDOCTYPEはありません。 - NTT DoCoMo iモード XHTML 1.0 → 文法
<!DOCTYPE html PUBLIC "-//i-mode group (ja)//DTD XHTML i-XHTML(Locale/Ver.=ja/1.0) 1.0//EN" "i-xhtml_4ja_10.dtd"> - NTT DoCoMo iモード XHTML 1.1 → 文法
<!DOCTYPE html PUBLIC "-//i-mode group (ja)//DTD XHTML i-XHTML(Locale/Ver.=ja/1.1) 1.0//EN" "i-xhtml_4ja_10.dtd"> - J-SkyWeb → 文法
- J-SkyWeb Station → 文法
J-SkyWeb用のDOCTYPEはありません。 - TTNet ドットi → 文法
ドットi用のDOCTYPEはありません。 - 特許出願用HTML → 文法
特許出願用HTML用のDOCTYPEはありません。
もしも、あなたが使用しているDOCTYPEがここになくて、そのDTDが存在している場合は、support@heartcore.co.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 が生成するようです。
5. DOCTYPE宣言に指定されている公開識別子の大文字小文字が正しくありません。*6*
DOCTYPE宣言中の "-//W3C//DTD HTML 4.01 Transitional//EN" などの公開識別子の大文字小文字は区別されます。
7. HTMLXXXX はすでに廃棄されたHTMLです。使わないようにしましょう。*3*
DOCTYPEに宣言されているHTML2.0やHTML3.0などは、すでに破棄されてしまった仕様です。使わないようにしましょう。
8. HTML4.0 はあまり薦められないHTMLです。HTML4.01 を使いましょう。 *3*
DOCTYPEに宣言されているHTML4.0は、使うことが薦められていません。改訂版のHTML4.01を使いましょう。この警告は減点されません。
10. DOCTYPE宣言は文書の先頭でなければなりません。 *5*
DOCTYPE宣言は、コメントやXML宣言を除く文書の先頭に書かなければなりません。つまり、<HTML> より前に書かなければなりません。
11. DOCTYPE宣言中の `HTML` は小文字で書かなければなりません。 *5*
DOCTYPE宣言 <!DOCTYPE HTML ～> にある HTML というのは、HTML文書が <HTML>～</HTML> で囲まれていることを示すものです。XML(J)では、要素名や属性名の大文字小文字が区別されます。大文字の <HTML> と小文字の <html> とは別物に解釈されます。すべての要素名が小文字のXHTML1(J)では、小文字の html でDOCTYPE宣言しなければなりません。
13. DOCTYPE宣言にはシステム識別子が必要です。 *6*
システム識別子は、DOCTYPE宣言中にあるDTDの所在を示す情報で、次のようなもの。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTMLでは、システム識別子を書かなければなりません。
14. DOCTYPE宣言に指定されているシステム識別子が正しくありません。 *6*
DOCTYPE宣言中に指定されているシステム識別子が正しくありません。公開識別子に対応するシステム識別子は決まっています。
16. SGML宣言や DTD宣言などと思われる <!XXXX ～> は無視します。
<!SGML ～> とか <!ELEMENT ～> とかいう宣言は、DOCTYPEを除いてすべて無視します。実際に存在する宣言かどうかはチェックしないので、でたらめな <!USO800 ～> とかでも黙って無視されます。実際には次のような宣言が存在します。
<!SGML ～> | |
<!DOCTYPE ～> | |
<!ELEMENT ～> | |
<!ATTLIST ～> | |
<!ENTITY ～> | |
<!NOTATION ～> | |
<!SHORTREF ～> | |
<!USEMAP ～> | |
もしも、タグをコメントアウトするつもりで "<!IMG ～>" などと書いているなら、それは "<!--IMG ～-->" と書かなければなりません。
17. マーク区間 <![XXXX[ ～ ]]> は、多くのブラウザは理解できません。
マーク区間というのは、<![CDATA[ ～ ]]> のようにしてSGML文書の一部分にいろいろな性格付けをしたりするものですが、多くのWWWブラウザはこの書式を理解できませんし、Another HTML-lint 5 もきちんとは解釈できません。HTML4.01(J)にもあまり使わない方がいいと言及があります。
マーク区間には次のようなものがありますが、いちいちスペルチェックはしていません。
<![CDATA[ ～ ]]> | |
<![RCDATA[ ～ ]]> | |
<![IGNORE[ ～ ]]> | |
<![INCLUDE[ ～ ]]> | |
<![TEMP[ ～ ]]> |
XHTML1(J)では、<SCRIPT> などの要素がCDATAではなく#PCDATAになっているので、旧来のように記述するためには、
<script>
<![CDATA[
... unescaped script content ...
]]>
</script>
としなければならなくなりました。Another HTML-lint 5 では、CDATAマーク区間のみ、HTML4以上に限って解釈しています。他のマーク区間は、入れ子の関係が許されたりいろいろ複雑なので、かなり大雑把にしか扱っていませんし、意味を斟酌してもいません。覚え書きを見てください。
また、構文上 <![ CDATA [ のように空白を含められるのですが、手抜き実装のため、複数行に渡っての記述は解釈できません。閉じる場合も同様です。
この警告は減点されません。
18. マーク区間中に `XX` を書くことはできません。 *6*
一般のマーク区間中には、次の文字列を記述することはできません。XML(J)。
]]> | |
< | |
& |
CDATAマーク区間では、次の文字列が書けないことになっています。
]]> |
スクリプトやスタイルシートの記述中にこういう字面を含むようなものをHTML中に埋め込むことはできません。そのようなときは外部にスクリプトやスタイルシートを用意しなければなりません。
ただし、チェックはCDATAマーク区間のみHTML4以上に限って行なっています。実際にこのエラーが出ることはありません。
20. XML宣言は文書の先頭でなければなりません。 *6*
<?xml で始まるXML宣言は、文書の先頭に書かなければなりません。つまり、DOCTYPE宣言よりも前に書かなければなりません。
21. XHTML では XML宣言をすることが強く求められています。 *3*
XHTML1(J)では、XML宣言をするように強く求められています。例えば次のようなもの。
<?xml version="1.0" encoding="UTF-8"?>
23. このXML宣言は正しくありません。 *6*
XML宣言の書式はXML(J)で決められています。ここで、属性の順序なども固定的であることに注意してください。Another HTML-lint 5 では、具体的な属性値に立ち入ってまではあまりチェックしていませんが、version="1.0" であることはチェックされます。
24. 処理命令 `<?～>` は理解できません。
Another HTML-lint 5 はXML(J)を解釈できないので、XMLに対して文法チェックしてもあまり意味がありません。実際には、"<?" はXMLに限らず、一般のシステム依存の何かの処理命令を示すマーク付けです。HTML4.01(J)にあるように、一般的には処理命令を閉じるのは ">" ですが、XML宣言を閉じるのは "?>" です。
古いWWWブラウザなどは、処理命令がそのまま表示されてしまうことがあります。この警告は減点されません。
25. コメント中に `--` は書かない方が安全です。 *3*
HTML中でのコメントは、"<!-- ～ -->" と書きますが、この "～" の部分に "--" を書くには注意が必要です。RFC1866(J)では、"--" と "--" の間がコメントとみなされ、その組が複数回現れてよく、それらの組と組の間は空白文字だけが書ける、となっています。つまり、次のような書き方は間違いです。
<!----------->
<!-- FOO -- BAR -- BAZ -->
最初の例は、"--" が正しく組になっていませんし、次の例は組と組の間が空白ではありません。以下の例は正しいのです(ただしRFC1866として)。
<!------------>
<!-- FOO --
-- QUZ -->
上の例は、ハイフン "-" が 12個で、ちょうどうまく組になるのです。
Another HTML-lint 5 では、このような正確な仕様を調べるのではなく、単純に余計な "--" が現れただけで警告するようにしています。しかし、多くのWWWブラウザでは、このようなコメント中のハイフンの扱いについては、相当寛容です。
26. コメント中に `--` を書くことはできません。 *5*
HTML4.01(J)では、コメント中に 2個以上連なったハイフンは書かないように、とされています。XML(J)でも禁止です。つまり、上の例はすべて誤りです。
27. 空のコメント `<!>` は書かない方が安全です。 *
RFC1866(J)では、空のコメント "<!>" は、"--" がゼロ組のコメントとして正しいコメントとされています。でも、書かない方がいいでしょうね。混乱の元です。XML(J)にはこのような表記は存在しません。
29. <TITLE> 中にはコメントを書かないようにしましょう。 *3*
<TITLE>中には、コメントも含めてテキスト以外は書かないようにとされています。HTML4.01(J)を見てください。
30. コメント中に `<` や `>` を書くと、いくつかのWWWブラウザを混乱させることがあります。*
HTMLの一部をまとめて
<!-- <A href="～">なんたら</A> -->
のようにコメントアウトすることはごく普通に行なわれると思いますが、一部のWWWブラウザでは、
<!-- <A href="～">
までをコメントとみなしてしまうものがあるそうです。これは、WWWブラウザが悪いというよりも、古いHTMLでこのような実装がされ得ていたようです。今時のWWWブラウザではこんなことはないようです。この警告は減点されません。
31. コメントを入れ子にすることはできません。 *6*
コメントを入れ子にすることはできません。
<!-- <!-- かんたら --> -->
このようなとき、多くのWWWブラウザでは、
<!-- <!-- かんたら -->
までがコメントとみなされて、残りが宙に浮いてしまいます。SGML的には「かんたら」の部分が非コメント部分とみなされてうまくありません。
32. 閉じコメントの `--` と `>` の間には空白を入れないようにしましょう。 *
仕様上は、"<!-- ～ -- >" と書いてもいいことになっています(XML(J)では禁止)。しかし、逆に "<! -- ～ -->" とすることは禁じられています。このときは、< とタグ要素名の間に空白が含まれていると警告されます。
33. 閉じコメントは `--!>` ではなく `-->` です。 *6*
読んで字の如くです。WWWブラウザによっては気を利かせて "--!>" の位置でコメントを閉じてくれますが、そうでない場合は、その後ろの記述がずっと無視されることになります。
また、コメントを "<!- ～ ->" と勘違いしている人もあるようです。
34. NN行目のコメントが閉じられていません。 *6*
"<!--" が現れたのに "-->" が最後まで現れなかったときの警告です。コメントを入れ子にしたりして、どこか間違えたのでしょう。
36. `<` と `TAG` の間には空白を入れてはいけません。 *6*
タグの開始は、"<TAG" のように続けて書かなければなりません。"< TAG" のように書いてしまうと、タグとして認めてもらえません。もしも、"<" を "<" という文字の意味で書いたのなら、それはそれで "<" と書かなければなりません。これについては、実体参照に関する警告を参照してください。
特許出願用HTMLでは、これが許可されているのですが、あまりにもひどい許容なので、この場合でも警告されます。
37. 予期せぬ `<` が <TAG> 内にあります。閉じられていないタグの可能性があります。 *6*
閉じるのを忘れたタグの後に正しいタグがある場合に出ることが多い警告です。
<A href="～"><IMG src="～" </A>
といった調子です。このとき、</A> の前に ">" が補われます。
もっと本当のことを言えば、実はこれはSGML的には間違っているとは言えません。SGML宣言で SHORTTAG YES のときにはタグの連続で直前のタグの > を省略してもいいことになっているからです。HTMLはどれも SHORTTAG YES です。終了タグだって、それがどの開始タグに対応するか自明な場合は </> としてもいいとか、もっといろいろあるんですが、そこまで正しいSGML的解釈をWWWブラウザに期待できません。HTML4.01(J)などを見てください。
38. 空要素タグ <TAG> は <TAG /> として閉じなければなりません。 *5*
XHTML1(J)では、<br> や <hr> などの空要素タグは、<br /> や <hr /> と書かなければなりません。
実際には、<br></br> と書いてもOKです。終了タグがないときの警告も参照してください。
39. 空要素タグ <TAG> を閉じるときは `/>` に空白を先行させましょう。 *3*
XHTML1(J)では、XMLを解さないユーザエージェントのために、空要素タグを閉じるときは <br /> や <hr /> のように /> の前に空白を先行させるように薦められています (Appendix C.2)。
なぜこれでXMLを解さないユーザエージェントのためになるのかというと次のような理由によるようです。
/ は、要素名とはなり得ない文字なのですが、<br/> という記述に対して古いユーザエージェントは br/ を要素名とみなし、未知のタグということで無視してしまうようです。これを <br /> とした場合は、既知の br なのでちゃんと改行される。ということのようです。
XML(J)ではこの空白はあってもなくても構いません。メディアタイプが application/xhtml+xml である場合は警告されません。
40. 空要素タグ <TAG> の要素には空白さえも含めることはできません。 *6*
XMLの Content of Elements(J)では、空要素タグは、<tag></tag> のように開始タグと終了タグをくっつけて書かなければならないとされてます。つまり、空白も含めることはできません。
41. 空要素タグは <TAG /> と書くようにしましょう。 *3*
XHTMLのガイドライン C.3(J)には、後方互換性のために、空要素タグは、<tag></tag> ではなくて、<tag /> と書くようにとされています。
メディアタイプが application/xhtml+xml である場合は警告されません。
42. 非空要素タグ <TAG> を `/>` で閉じることはできません。 *5*
XHTML1(J)では、<p> などの非空要素タグに対して、<p></p> を <p /> と表記してはならないことになっています (Appendix C.3)。
メディアタイプが application/xhtml+xml である場合は警告されません。
43. <TAGA> を NN行目の <TAGB>～</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> は書けないからです。
44. <TAGA> を NN行目の <TAGB>～</TAGB> 内に書くことはあまり薦められません。 *3*
とりあえず書いても大丈夫ですが、薦められていません。将来的に書けなくなる可能性があります。この警告は減点されません。
45. <TAGA> を <TAGB>～</TAGB> の外に書くことはできません。 *3*
タグによっては、ある条件で特定のタグの要素内にしか書けないものがあります。多くは内部に書けないと警告されますが、DTDで規定できない場合はこの警告が出ます。
<IMG ISMAP> は、<A HREF>～</A> の外には書けません。これは、HTML2.0 や ISO/IEC 1544 などに書かれています。
46. <TAGA> は <TAGB>～</TAGB> 内に1度しか書けません。NN行目にもありました。 *6*
タグによっては何度も書けないものがあります。<BODY> や <TITLE> や <CAPTION> などいろいろあります。これらは、HTML中で一度だけ書けるという意味ではなく、<BODY> ならばそれを書くことができる <HTML>～</HTML> 内で一度という意味です。<HTML> は一度しか書けないので <BODY> も一度しか書けないことになりますが、<CAPTION> は <TABLE>～</TABLE> 内で一度です。<TABLE> は何度でも書けるので、<CAPTION> 自体はHTML中に何度も現れることがあります。
47. <TAGA> は NN行目の <TAGB> と同時に <TAGC>～</TAGC> 内に書くことはできません。 *6*
例えば、HTML4.01(J)では、<BODY> と <FRAMESET> は、どちらも <HTML>～</HTML> 内に書くタグですが、両方を書くことはできません。これは、このような制限のあるタグに対する警告です。
48. <TAGA> は </TAGB> の直後に続かなければなりません。 *6*
決まった順序で書かなければならないタグがいくつかあります。<HTML>～</HTML> 内では、<HEAD> の次に <BODY> という順序でなければなりませんし、<TABLE>～</TABLE> 内では、<CAPTION> を <TR> などの後に書くことはできません。
49. <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> の連続に対してこの警告は出ません。
50. <TAGA>～</TAGA> 内には <TAGB> が必要です。 *6*
必ず書かなければならない要素があります。例えば、<HEAD>～</HEAD> 内に <TITLE> は必要です。
51. <TAG> と </TAG> の間が空です。 *
ある種のタグは、要素が空であるのが好ましくないことがあります。例えば、
<ADDRESS></ADDRESS>
などというのでは、何のための <ADDRESS> なのかわかりません。特に、<P> を <BR> の代わりに改行の意味で使っていたりすると、</P> が省略されているとみなされて、さらにこの警告が出ることが多くなります。<P> は段落のためのタグであり、改行のためにあるのではありません。
また、
<A name="anchor"></A>
としたのでは、Lynxなど一部のWWWブラウザではそこに飛べなくなってしまいます。文法的には間違っていないし、同じ場所に複数の名前を付けたりするのはよくやることだと思いますし、そもそもアンカーはその一点に指定するのであって、ある範囲に指定するのではありません。Lynxなどが飛べないのは、不具合に近いと思います。なお、最近のLynx(2.8.1)ではそのようなことはないようです。
52. <TAG> と </TAG> の間に空白文字しか含まれていません。 *3*
あるWWWブラウザで半角空白と異なる振る舞いをするからといって、全角空白 □ を利用して、<P>□</P> のように空白だけの要素を書いて桁揃えをしようとする試みが数多く行なわれています。これは、偶然うまくいくかも知れませんが、好ましくありません。しかし、これらが何らかの別の正当な意図的な目的で行なわれていないとも限りません。ここでは、全角空白の他に、半角カタカナ空白である     や、 も含めて空白文字とみなしています。
<TD> などの内容を空白だけにして、何らかの視覚効果を狙うのは、スタイルシートで行なうようにと、アクセス指針CSS技術文書に書かれています。この警告は減点されません。
53. <TAG>～</TAG> 内には空白以外に <BR> しか含まれていません。 *
<P> を <BR> のように使っていたら警告されたので <BR> に変えたら、今度は <BR> を <BODY>～</BODY> 内に書くことはできないと警告された。そこで <P><BR></P> と書いた。ということがあるのだそうです。
本質を理解しないまま満点を目指した結果なのですが、意図的に <P><BR></P> と書かないとも言いきれません。
<P> <TD> <TH> に対してだけ警告されます。この警告は減点されません。
54. <TAG> は不明なタグです。 *5*
文字どおり間違ったタグを書いています。スペルミスなどの可能性があります。多くの参考書で紹介されている <NOFRAME> というのは <NOFRAMES> の誤りです。また、<CENTER>～</CENTER> はあっても、<LEFT>～</LEFT> なんてのはありません。
各HTMLがどういうタグをサポートしているのかの一覧もあるので参考にしてください。
55. <TAG> は XXXX 用のタグです。 *5*
チェックしているHTMLのヴァージョンではサポートされていないが、他のヴァージョンでサポートされているタグです。あまりこの警告が大量に出るようなら、DOCTYPE宣言が適切でない可能性があります。 各HTMLがどういうタグをサポートしているのかの一覧もあるので参考にしてください。
56. <TAG> はあまり薦められないタグです。 *3*
このタグは、すたれつつあるタグです。将来はサポートされなくなる可能性があるので、使わないようにしましょう。例えば、次のように代替のタグを使います。
<CENTER> | → | <DIV align="center"> |
<DIR> | → | <UL> |
<MENU> | → | <UL> |
<ISINDEX> | → | <INPUT> |
<XMP> | → | <PRE> |
<APPLET> | → | <OBJECT> |
ただし、HTMLのヴァージョンによって警告されるタグが異なりますし、単純に要素名だけ替えればいいというわけではないので注意してください。
57. <TAG> はあまり薦められないタグです。スタイルシートを使いましょう。 *3*
HTML4.01では、<FONT> や <U> などが薦められないタグになっています。これらのタグは、文書構造を記述するという本来の目的からは外れたタグとして、スタイルシート(CSS1(J)/CSS2(J))を利用しなさい、ということです。それにしては、<B> や <I> などは外されていません。この警告は減点されません。
58. <TAG> は Another HTML-lint 5 では正確な評価はできません。
MSIE5.0でサポートされている <XML> や、<HTML xmlns:namespace> で宣言される custom Element を正確に解釈することはできません。
<XML> は、HTML中にXMLを挿入するのに用いますが、Another HTML-lint 5 ではXML名前空間等の解釈をすることはできません。<XML>～</XML> 内に書かれるタグは、開始終了タグの対応関係以外はチェックされません。この警告は減点されません。
60. ここには <TAG> が必要です。 *6*
省略できない開始タグが書かれていません。ISO/IEC 15445 などでは、<HTML> を省略することができません。XHTML1(J)では、すべての開始タグは省略できません。
61. ここに <TAG> が省略されているようです。省略しないようにしましょう。 **
開始タグの省略は、HTMLではあまり行なわれないようですが、仕様上は省略が許されているタグがあります。<HTML> や <HEAD>、<BODY> などの開始タグは省略することができます。だからといって、省略はしないようにしましょう。
タグのひとつもないプレーンなテキストをHTMLとして評価しようとすると、省略可能なタグが補われて、次のようなHTMLだとみなされますが、<HEAD> に必要な <TITLE> が含まれていないので、正しいHTMLとはなりません。<TITLE> タグは省略可能ではないので、自動的に補うことができません。
<HTML>;
<HEAD>;
</HEAD>;
<BODY>;
テキスト;
</BODY>;
</HTML>
こんなのは勘弁して欲しいものです。
62. ここに <TAG> が省略されているようです。 **
HTML4.0で拡張されたタグのうち、古いヴァージョンとの互換のために開始タグの省略できるものがあります。例えば、HTML3.2(J)などでの次のようなTABLEがそうです。
<TABLE>;
<TR><TD>うはうは</TD></TR>;
</TABLE>
これはHTML4.01では
<TABLE>;
<TBODY>;
<TR><TD>うはうは</TD></TR>;
</TBODY>;
</TABLE>
とみなされますが、<TBODY> と </TBODY> は省略できます。この警告は減点されません。
64. ここに </TAG> が省略されているとみなします。 **
省略可能である終了タグは、たくさんあります。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はこれを許してくれない。
65. ここに </TAG> が省略されているとみなします。 **
</LI> や </DT> などの省略が自明な場合に出ます。上の解説を参照してください。この警告は減点されません。
<P> を連続して
<P>ほにゃらら
<P>へにょろろ
のように用いているとき、この場合「ほにゃらら」の後ろの </P> は省略が自明だとみなされます。「へにょろろ」の後ろの </P> は、さらに <P> が続けば自明な省略とみなされますが、そうでない場合は自明とはみなされません。
Laura Lemay のHTML本では </LI> は存在しないものとして解説されているけど、この本が書かれた時点のHTMLがそうだったからに過ぎず、現在のほとんどのHTMLでは </LI> は存在します。これを鵜呑みにして </LI> を存在しないものとしているおばかな参考書もあるので気を付けましょう。
ところが、残念なことにHTML4.0対応を謳ったHTML入門第2版でも「<LI> に終了タグは存在しない」と書かれているので注意してください。このシリーズ、初版から内容の全面的見直しをしてないようだ。
67. <TAG> には終了タグ </TAG> はありません。 *6*
<BR> のようなタグには終了タグ </BR> は存在しません。ただし、HTMLのヴァージョンによって、終了タグのあるものとないものがあります。例えば、HTML3.2(J)などでは <BASEFONT> に終了タグはありませんが、Mozillaの場合は </BASEFONT> が存在します。
XHTML1(J)ではすべてに終了タグが存在します。空要素タグは
<br />
<br></br>
のどちらで表記しても構いません。前者は、後者の短縮形です。空要素なので、
<br>むにゃむにゃ</br>
などと何か内容を入れることは当然できません。
68. <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>
この警告は、状況を細分して減点したりしなかったり制御すべきなのですが、そこまでできていません。つまり、インライン要素の開始タグ直後の空白のみ減点し、他は非減点にすべきであろうと考えています。とりあえず、この警告は減点されません。
69. </TAG> に対応する開始タグ <TAG> が見つかりません。 *6*
ほとんどの開始タグは省略できないので、それらの開始タグなしに終了タグは存在し得ません。開始タグを消したときの修正漏れの他に、タグの入れ子関係がおかしくなっているときの副作用のこともあります。
70. <TAGA> は NN行目の <TAGB> と重なり合っているようです。 *6*
次のように、開始タグと終了タグの関係が入り乱れているときにこの警告が出ます。
<P>むかしむかし<BIG>でかい桃が</P>どんぶらこ</BIG>
このような単純な間違いはいいのですが、タグの入れ子が深いときなど、ひとつタグを間違えただけで、この警告がたくさん出ることがあります。
71. <TAG> の入れ子が深過ぎます。 *6*
入れ子にできるタグのレベルは、SGML宣言(J)の QUANTITY TAGLVL で指定されていて、たいてい 100です。
この警告に出てくる <TAG> は、そのタグでエラーが起こったことを示すだけです。<TAG> だけ 100レベルも入れ子になっているわけではありません。
72. NN行目の <TAG> に対応する終了タグ </TAG> が見つかりません。 *6*
省略できない終了タグを書いていないときに警告されます。よく、</A> を書いていないことがあります。WWWブラウザによっては適当に </A> を補ってそれなりのリンクが張られるものもありますが、全然うまくいかない場合もあります。この </A> を書いていないケースでは、<A> の中に <A> を書いていると警告されることも多いです。
省略できる終了タグについても目を通しておいてください。
73. <TAG>～</TAG> 内に普通のテキストを書くことはできません。 *6*
<HEAD> や <UL> などの要素には、決められたタグしか書けません。
<UL>なんじゃこりゃ</UL>
みたいに書くことはできないわけです。これは、
<UL><LI>なんじゃこりゃ</UL>
が、正解です。
HTML4.01 Strictでは、<BODY>～</BODY> 内にも普通のテキストを直接書くことはできなくなっています。つまり、
<BODY>
例えばこういう風に書く
</BODY>
とは書けないのです。正しくは、次のようにします。
<BODY>
<P>
例えばこういう風に書く
</P>
</BODY>
このように、<BODY> にはブロックレベル要素しか書けません。
74. <TAG> 内におかしな文字列 `XXX` があります。 *6*
タグの要素名や属性名は、(いわゆる半角の)英数字、ピリオド "."、ハイフン "-" から成り、先頭は英字です。HTML4.01(J)では、下線 "_" とコロン ":" も書けるようになっています。属性値に空白など他の文字を含めたいときなどは引用符で囲む決まりです。タグ内の引用符の外側に、これら以外の文字があったときに警告されます。よくあるのが、ハイフン "-" と下線 "_" を間違えているケースや、属性の区切りに全角空白を書いていたり、属性名を全角にしているケースです。ひとつでもこういうのがあると、そのタグ内でこのエラーがたくさん出ます。
予期しない "<" が現れたときの警告についても見てください。
76. 要素名や属性名の大文字小文字を統一するようにしましょう。 *
タグの要素名や属性名の大文字小文字は同一視されるので、次はすべて同じです(XHTMLを除く)。
<BLOCKQUOTE>
<BlockQuote>
<blockquote>
HTML中でこれらを大文字か小文字かどちらかに統一して書いていた方が美しかろう、という(多分に宗教臭い)警告です。要素名、属性名それぞれ独立にチェックされます。HTML4.01(J)のリファレンスでは、要素名は大文字、属性名は小文字で書かれていて、その理由は読み易くするためだ、と言ってます。
この警告は、Weblintを引き継いだだけの警告で、減点されません。
XML(J)では要素名や属性名の大文字小文字は区別されるので、どれでもいいというわけにはいきません。決められているとおりに大文字小文字のメリハリを付けて書く必要があります。XHTML1(J)では、要素名、属性名は小文字に決められているので小文字で書かなければなりません。
79. <TAG> に不明な属性 `ATTR` が指定されています。 *5*
間違った属性が指定されています。スペルミスなどの可能性があります。しかし、参考書があからさまに間違った解説をしていないとも限りません。例えば、Mozillaを解説したある参考書では、<LAYER> に名前を付けるのにNAME属性を使うよう指導しています。Netscape社のサイトを見ればわかりますが、これはID属性の誤りです。
80. <TAG> に XXXX 用の属性 `ATTR` が指定されています。 *5*
チェックしているHTMLのヴァージョンではサポートされていないが、他のヴァージョンでサポートされている属性です。あまりこの警告が大量に出るようなら、DOCTYPE宣言が適切でない可能性があります。
81. <TAG> の属性 `ATTR` はあまり薦められない属性です。 *3*
この属性は、すたれつつある属性です。将来はサポートされなくなる可能性があるので、使わないようにしましょう。ここで指摘される属性には、スタイルシートによる代替はありません。特に<A>のTARGET属性は、その利用自体が薦められていません。フレームの利用や、強制的な方向付けはやめましょう。
XHTML1.0(J)では、<A>などのNAME属性は薦められていません。ID属性を使いましょう。XHTML1.1では、そのようなNAME属性は廃止されています。
82. <TAG> の属性 `ATTR` はあまり薦められない属性です。スタイルシートを使いましょう。 *3*
スタイルシート(CSS1(J)/CSS2(J))での代替を薦められている属性です。残念ながら、これらの属性すべてがスタイルシートで置き換え可能なわけではありません(CSS2では可能?)し、スタイルシートをサポートしていないWWWブラウザのためには使わざるを得ないとも思います。この警告は減点されません。
83. <TAG> の属性 `ATTR` は Another HTML-lint 5 では正確な評価はできません。
MSIE5.0でサポートされている <HTML xmlns:namespace> を正確に解釈することはできません。
xmlns:namespace は、指定された namespace を <STYLE>～</STYLE> 内で定義し、<namespace:xxx>～</namespace:xxx> のように参照します。この警告は減点されません。
84. <TAG> の ATTR 属性の前には空白が必要です。 *6* または **
属性の指定を
<BODY bgcolor="#FF00FF"link="#808080">
のように続けて書いているときに警告されます。この例では link の前に空白がありません。
HTMLでは、なくても文法上エラーではありませんが、XHTMLでは文法違反です。
85. <TAG> で ATTR 属性の指定が繰り返されています。 *5*
タグで指定する属性は、同じものを何度も指定することはできません。
<BODY bgcolor="#FF00FF" bgcolor="#808080">
なんてのはだめです。
86. <TAG> には ATTR 属性が必要です。 *6*
タグによっては、必ず指定しなければならない属性のあるものがあります。HTML3.2(J)の <BASE> のHREF属性などがそうです。また、<AREA> のALT属性は必須です。<IMG> のALT属性はHTML3.2では必須ではないのですが、HTML4.01では必要な属性となっています。ALT属性の使用を促す警告も見てください。
87. <TAG> で ATTRA 属性を使うときは ATTRB 属性も必要です。 *3*
NTT DoCoMo iモードでは、同時に指定しなければならない属性があります。
<A IJAM HREF><A TELBOOK KANA EMAIL HREF>
88. <TAG> で ATTRA 属性と ATTRB 属性を同時に指定することはできません。 *3*
NTT DoCoMo iモード 4.0では、同時に指定してはならない属性があります。
<A IJAM><A ISTA>
89. <TAG> の ATTR 属性には属性値が必要です。 *5*
多くの属性は属性値を伴って指定されます。
<BR clear>
では不完全です。
<BR clear="all">
のように属性値を正しく指定しましょう。
<BR clear=>
なんて書いたときは別の警告が出ます。
91. <TAG> の ATTR の属性値が複数行に渡っています。 *
引用符で囲んだ属性値は、行をまたいで書いても構いません。改行はただの空白と同じ扱いです。
<AREA shape="rect" coords="10, 12, 50, 76">
とかいう具合なんですが、まあ、一応警告しときます。この警告は減点されません。
92. <TAG> の ATTR の属性値区切りの = 前後に空白が含まれています。 *
RFC1866(J)では、属性と属性値とを区切る = の前後には空白を含めてもいいことになってるんですが、それをわざわざ警告するHTMLチェッカも存在するのでこの警告があります。この警告は減点されません。
93. <TAG> の ATTR の属性値の引用符が閉じられていません。 *3*
属性値を引用符で囲んでいる場合、その中に ">" が現れると、タグが閉じられてしまう可能性があります。
<IMG src="～" alt="a>b">
のようなのは、
<IMG src="～" alt="a>b">
と、実体参照を用いて書くようにしましょう。これについては、RFC1866(J)で言及されていて、本来は間違いとは言えないのですが、実際に引用符を閉じ忘れている場合との区別が厳密にはつかないため、Another HTML-lint 5では文法的な間違いとしています。
94. Lorem Ipsum is simply dummy text of the printing and typesetting
属性値の文字列を囲む引用符には、二重引用符 "～" と単引用符 '～' のどちらでも使用できます。これらの使い分けは、主に二重引用符自身を表現したいときに、いちいち " と書くのがわずわしいので単引用符で囲む、というものです。
"We say "So!""
'We say "So!"'
これらは、どちらも同じです。しかし、単引用符を解釈しないWWWブラウザが存在するそうです(MSIE for MacOS が該当します)。この警告は減点されません。
ところで、ある参考書に "～" 中に " を書くには \" とするなどと書いたのがありました。どうしてそんな解説が書けるのか不思議でなりません。JavaScript中などとごっちゃになってるんですかね。
95. <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%> とかいう例が載っているけど、これらは間違いです。
96. <TAG> の ATTR の属性値 `XXXX` は引用符で囲んだ方が安全です。 **
HTML4.01(J)で、下線 "_" やコロン ":" を含む文字列を引用符で囲んでいないときにこの警告が出ます。他のHTMLのことも考えれば囲んだ方が安全です。
97. <TAG> の ATTR の属性値 `XXXX` が引用符で囲まれていません。 *
引用符で囲む必要のない裸で指定されている属性値に対して、注意を促します。これは、好みで全部囲まなきゃ気が済まないときなどにチェックするようにしましょう。それ以外ではたぶん不要です。この警告は減点されません。
98. <TAG> の ATTR の属性値 `XXXX` は空白文字が先行または後行しています。 *
決まった値や数値などを取る属性の値に空白を先行、後行させたときに出ます。
<P align=" center">
<UL type="disk ">
<LI value=" 5 ">
これらが間違いかどうかはよく知らないのですが、文書記述言語SGML(内容は日本工業規格だからそれなりだけど、HTMLとしては無惨極まりない)の 6. 要素構造 によると、正しくないように読めます。
XHTML1(J)には、属性値の先行後行する空白は無視され、それ以外の連続する空白は単一の空白として扱われると書かれています。つまり、上の例はすべて正当です。
99. <TAG> の ATTR の属性値 `XXXX` はあまり薦められない値です。 *3*
この値は、すたれつつある値です。将来は指定できなくなる可能性があるので、使わないようにしましょう。
100. <TAG> の ATTR の属性値に空の値を指定することはできません。 *5*
決まった値や数値などを取る属性は、値に空を指定することはできません。このような属性は多数あります。
<P align="">
<UL type="">
<LI value="">
これらはいずれも正しくありません。<IMG alt=""> のように、空にできる属性もあります。
<IMG src=""> のようにURIを空にした場合は違う警告が出ます。
101. <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文字に勘定しています。
102. <TAG> の ATTR の属性値 `XXXX` は正しくありません。 *5*
属性値として、取り得る値が決められているものが多くあります。例えば <DIV ALIGN> には LEFT、CENTER、RIGHT のいずれか、<BR CLEAR> には ALL、LEFT、RIGHT、NONE のいずれかしか書けないなどです。
- <BASEFONT SIZE> は 1～7 だけが指定できますが、<FONT SIZE> には "-3" とか "+1" とか符号を先行させることができます。
- 幅を示す WIDTH属性には、数字だけの他に、"50%" とか "3*" のような指定ができるものがあります。スタイルシートと混同してか、"180pt" のような単位を付けられるような誤解があるようですが、そのようなHTMLは今のところ存在しません。
- ACCESSKEY属性は、ASCII１文字しか指定できません。
- フォームコントロールなどで指定する TABINDEX属性の値は、HTML4.01(J)で、0～32767 の範囲に制限されています。
- ID属性は、HTMLでは、属性名などと同じに、英字から始まり英数字とハイフン "-" とピリオド "." から成らなければなりません。HTML4.01(J)では、下線 "_" とコロン ":" が追加されました。小文字のIDに関する警告も参照してください。
XHTMLでは、英字または下線 "_" から始まり、英数字とハイフン "-" とピリオド "." と下線 "_" などから成らなければなりません。コロンは含まれまれないことに注意してください。XHTMLでは、ASCII文字以外もIDに利用できるのですが、Another HTML-lint 5 ではチェックしていません。ASCII文字以外のIDはエラーになります。 また、大文字小文字を問わず、"xml" から始めることは禁止されています (XML1.0 2.3 Common Syntactic Constructs)。 - LANG属性の値は、ISO0639に従わなければなりません。
103. <TAG> の ATTR の属性値 `XXXX` は正しくありません。#RRGGBB の形式か決められた色の名前でなければなりません。 *5*
BGCOLORなどの色の指定は、"#00FF80" のような特別な形式でRGBを指定するか、決められている色の名前を指定します。HTML3.2(J)やHTML4.01(J)では 16色に名前が付けられていますが、MozillaやMSIEでは拡張されていて全部で 140色に名前が付いています。
104. <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 5 は、PROFILE属性を空白区切りの複数のURI列として評価します。この警告は減点されません。
105. <TAG> の ATTR の属性値 `XXXX` は使わない方が安全です。 *3*
XHTMLのID属性の値は、HTMLのそれとは異なっており、互換性もありません。下線 "_" から始まるID値は、XHTMLで使えますが、HTMLでは使えません。そのような値は避けるようにしましょう。
107. <TAG> の ATTR の属性値は `XXXX` でなければなりません。 *5*
ごく一部の属性は、取り得る値が固定されているものがあります(DTDで#FIXEDが指定されているもの)。そのような属性では、固定されている値以外を指定することはできません。
108. <TAG> の ATTR は属性名と属性値が同一です。属性名を省略して属性値だけの指定にしましょう。 **
例えば、
<DL compact>
というのは、
<DL compact=compact>
の属性名の compact= の部分を省略した書き方です(属性値を省略しているのではありません)。したがって、本来ならばこのような省略しない書き方もできるはずなのですが、こういうのを解釈しないWWWブラウザもあるようです。省略した書き方をするようにしましょう。
109. <TAG> の属性 `ATTR` で属性名を省略することはできません。 *5*
属性値の引用符を省略できないXHTML1(J)では、属性名を省略した短縮形を書くことはできません。例えば、
<dl compact>
というのは、
<dl compact="compact">
と書かなければなりません。
110. <TAG> の `XXXX` は属性名 ATTR が省略されていますが、うまく評価されないかも知れません。 **
属性名の省略は、何も compact=compact のような場合だけではなく、
<P center>
のように書いてもいいことになっています(XHTML1を除く)。これは、
<P align="center">
の省略形です。こういうのは、他に center という値を取る属性が存在しないときに可能なのですが、ここまで省略形をきちんと解釈してくれるWWWブラウザはなかなかないようです。
HTML4.01で <TABLE border> という風に書くと、これは、<TABLE frame=border> と解釈されるので注意してください。
111. 実体参照 `&xx` の後ろには `;` を書きましょう。 *3*
実体参照というのは、< や & みたいな書き方のこと(正確には後者は文字参照)で、テキスト中に "<" や ">" など直接表現できない文字を書くときの方便です。実体参照は "&" で始まって ";" で終わります。SGMLでは、終わりのセミコロンは、省略が自明な場合は書かなくてもいいことになっています。例えば、
abc < xyz
112. 実体参照 `'` は `'` と書くようにしましょう。 *3*
XHTML 1.0 (Second Edition) の C.16 に、後方互換性のために、' は使わないで ' と書くようにとされています。
113. XHTML では 16進数の文字参照は `ሴ` と小文字で始めなければなりません。 *3*
大文字小文字の区別されるXHTMLでは、16進数の文字参照も &#x と小文字で始めなければなりません。ሴ は誤りです。
114. `&xx;` は不明な実体参照です。 *3*
"<" や ">" など実体参照で参照される名前は、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中の実体参照が展開されないそうです。
115. 文字参照 `&#NNN;` は限界を超えた文字コードです。参照できるのは `&#MMM;` までです。 *6*
& のような文字参照で参照できる文字コードは、HTMLごとに定められています。例えば、HTML2.0やHTML3.2では 255まで、HTML4.0では 1114111までです。これはSGML宣言に記述されています。これより大きな値を与えると警告されます。MozillaやMSIEではチェックされません。DTDが存在しないからです。
117. メタ文字 `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 にあります。
118. テキスト中の `"` は `"` と書きましょう。 *
安全のために、テキスト中の引用符 " を実体参照を用いて表現するように促す警告です。実際にはその必要はありません。この警告は減点されません。
119. <HTML> には LANG 属性を指定するようにしましょう。 *3*
<HTML> には、LANG属性を使ってその文書の言語を明示しておくことがWAIで薦められています。日本語の場合は次のようにします。
<HTML lang="ja">
<HTML lang="ja-JP">
HTTPレスポンスヘッダ中で Content-Language によって言語コードが指定されている場合は警告されません。
XHTML では xml:lang属性を使いますが、XHTML1.0では、両方を書くように薦められています。
LanguageCode は、ISO0639にあります。
121. <tag> に指定されている lang 属性の値と xml:lang 属性の値が食い違っています。 *3*
XHTML で lang属性と xml:lang属性の両方を併記したとき、その値は一致していなければなりません。
122. 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 5 は主に日本語で書かれたHTMLを対象にしているので、このように文字コードによる判定を行なっています。
XHTML では xml:lang属性を使います。
123. 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 5 は主に日本語で書かれたHTMLを対象にしているので、このように文字コードによる判定を行なっています。
XHTML では xml:lang属性を使います。
124. <HEAD>～</HEAD> 内に <LINK REV="MADE" HREF="mailto:～"> が含まれていません。 *
Lynxなどの一部のWWWブラウザは、この情報を解釈して、このメールアドレスへ直ちにメールを出したりできます。HTML作者を明示するためにも、このタグは入れるようにしましょう。
しかし、古いMozillaは <LINK> タグをサポートしていないので、このタグをせっかく書いても、Another HTML-lint 5 ではエラーが出ますが、気にしないでください。Mozilla4.0 になってようやく <LINK> がサポートされました。
と、指定を薦めているにもかかわらず、HTML4.01では、リンク形式に MADE は含まれていません。また、指定があれば mailto: である必要もありません。この警告は減点されません。
125. <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で用意するように指示されています。この警告は減点されません。
126. <LINK> の REL の属性値 `CONTENT` は `CONTENTS` の誤りだと思われます。 **
ナヴィゲーション用に目次ページを示すのは複数形の "CONTENTS" です。
127. <META NAME="ROBOTS"> に指定されている CONTENT 属性の値 `XXXX` はあまり薦められません。 *
検索ロボットについてHTML4.0中にも言及があります。CONTENT属性に記述できるのは、 "ALL"、 "NONE"、 "INDEX"、 "NOINDEX"、 "FOLLOW"、 "NOFOLLOW" で、しかもそれらの大文字小文字は区別されます (大文字小文字に関しては正誤表参照のこと)。 HTML Author's Guide to the Robots META tag も見てください。 ただし、この中にも自己矛盾的な内容を含んでいます。
しかし、HTML4.01(J)からは、こういった大文字小文字に関する記述がきれいさっぱり削除されてしまっています。この警告は減点されません。
"NOARCHIVE" は、ロボットを排除する値としてよく利用されていますが、robotstxt.org の仕様には含まれていません。
128. <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 である場合は警告されません。
129. <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- で始まるものに関しては減点されません。
130. <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="～"> に CHARSET を指定するようにしましょう。 **
CHARSETの指定はなくてもいいのですが、RFC1945やRFC2068によると、指定しなかった場合は、ISO-8859-1が仮定されることになっています。日本語を書く場合はきちんと指定しなければなりません。
メディアタイプが application/xhtml+xml である場合は警告されません。
131. <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 である場合は警告されません。
132. 非ASCII文字が含まれています。 *5*
CHARSETで指定してあるコードが、US-ASCII、ISO-2022-JP のような 7bitコードのときに、非ASCIIコードが含まれていると警告されます。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
133. 制御文字 `^X` が含まれています。 **
改行やタブ、JISのエスケープシーケンスなど以外の制御文字(0x00～0x1F)が含まれているときに警告されます。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
134. 半角カタカナが含まれています。 **
CHARSETにShift JISが指定してあるときに、半角カタカナ(JIS X 0201 のカタカナ部分)が含まれていると警告されます。また、JISのときは ^[(I という半角カタカナ用のエスケープシーケンスが現れると警告されます。EUCでも半角カタカナが表現できますが、チェックしていません。^[(I というエスケープシーケンスは、ISO-2022-JPでは規定されていません。つまり、ISO-2022-JPと宣言しておいてこのエスケープシーケンスを用いるのは誤りです。
なぜ半角カタカナがだめなのかは、RFC1468や半角カナの危険性やなぜ半角カナは嫌われるのか(メモ)などを参考にしてください。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
NTT DoCoMo iモード、特許出願用HTMLでは、半角カタカナの使用が許可されています。この場合、警告はされますが減点されません。
135. 機種依存全角文字 `XXXX` が含まれています。 **
日本語の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での使用が許可されている一部の丸付き数字の場合は警告されません。
136. 文書の先頭に BOM が含まれています。
文書の先頭にBOM(Byte Order Mark)と呼ばれる制御コードが含まれています。UTF-8のBOMは、0xEF 0xBB 0xBF です。 この警告は減点されません。
137. XHTML では XML宣言中に encoding 指定をしましょう。 *3*
XHTML Media Types(J) によると、XHTMLでは、XML宣言中にencoding指定をすることが強く求められています。メディアタイプ application/xhtml+xml のときは、HTTPレスポンスヘッダにCHARSET指定がある場合でも同様です。
138. 指定されている文字コードセットは `XXXX` ですが、実際のコードは YYYY のようです。 *5*
せっかくCHARSETで文字コードを指定してあるのに、実際には異なる文字コードでHTMLが記述されています。このような文書は、CHARSETを正しく解釈するWWWブラウザではまったく読むことができません。日本語の指定(JIS、EUC、Shift JIS、UTF-8)のみチェックしています。XML宣言中のencoding指定の方が優先します。HTTPレスポンスヘッダにCHARSET指定がある場合は、さらにそちらを優先します。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
139. 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領域に指定した場合は、このエラーはチェックされません。
140. HTTPレスポンスヘッダに CHARSET 指定が含まれていません。 *3*
HTTPレスポンスヘッダ中に CHARSET 指定をすべきです。 XHTML Media Types(J) でも強く求められいます。 しかし、これはサーバ側の問題です。 HTTP経由のチェックのときのみ警告されます。
141. <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 だと誤解されている方もいらっしゃるようですが、それは違います。そのようなメディアタイプは定義されていません。
142. HTTPレスポンスヘッダに指定されているメディアタイプは `xxxx/xxxx` ですが、<meta> に指定されているのは `yyyy/yyyy` です。 *5*
現在HTMLとして受け付けられるメディアタイプは、text/html と application/xhtml+xml です。HTTPレスポンスヘッダに指定されているメディアタイプと<meta>に指定されているそれが食い違っています。しかし、そもそも application/xhtml+xml では、<meta http-equiv> を記述すべきではありません。
143. 指定されているメディアタイプ xxxx/xxxx は YYYYYY には指定しないようにしましょう。 *3*
XHTML Media Types(J) によると、HTMLに対して application/xhtml+xml を指定するのは禁止され、XHTML1.1に対して text/html を指定することを推奨していません。 XHTML1.0に対しては警告されません。
144. メディアタイプ application/xhtml+xml には <meta http-equiv> を記述すべきではありません。 *4*
XHTML Media Types(J) によると、メディアタイプが application/xhtml+xml である文書では <meta http-equiv> を記述すべきではないとされています。
145. <META HTTP-EQUIV="CONTENT-TYPE"> は NN行目にもありました。 **
誤りではないのかも知れませんが、一度にしておいた方が無難でしょう。
HTTP-EQUIV="REFRESH" に対しても同様の警告が出ます。
146. <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 属性などに対しても同様です。
147. 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 が採用されることが期待できるように書かれているのですが、指定しなくてもいいわけではありません。
148. <META> に HTTP-EQUIV 属性と NAME 属性の両方を指定することはできません。 *5*
HTML4.01(J)では、HTTP-EQUIV 属性は NAME 属性の代わりとして使われるものとされています。つまり、これらを併記することはできません。
149. <META> に CONTENT 属性を指定するときは HTTP-EQUIV 属性か NAME 属性を指定しなければなりません。 *5*
<META> には、CONTENT 属性が必要ですが、HTML4.01(J)では、META要素は名前と値とを対で指定するように書かれています。つまり、CONTENT 属性だけでなく、HTTP-EQUIV 属性または NAME 属性が必要です。このような、どちらかが必要という指示は、DTDでは表現できません。
150. ATTRA 属性を使うときは ATTRB 属性も指定しましょう。 *3*
スクリプトのイベント処理では、装置非依存性を確保するために、次の属性は対で使用するように、アクセス指針技術文書4.12.2(J)で薦められています。
| onmousedown | + | onkeydown | |
| onmouseup | + | onkeyup | |
| onclick | + | onkeypress | |
151. Lorem Ipsum is simply dummy text of the printing and typesetting
WAIでは、REFRESHによる自動的なページの更新は行なわないように書かれています。これは、利用者の意思が無視されてしまうのが主な理由です。
152. <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 5 では、とりあえず、区切り文字が "," か ";" かで区別するようにしてあります。
153. <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に変更されたので、この手法を適用するだけではうまくありません。マーク区間を利用してください。
また、そのためにそもそもコメントで囲む記述をすること自体が問題となります。外部にファイルを用意するよう促す警告を見てください。
154. <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 5 ではそこまでは見ていません。
155. <SCRIPT>～</SCRIPT> 内に `XX` を書くときは外部にスクリプトを用意しましょう。 *3*
HTMLで、<SCRIPT> や <STYLE> 内に、次のような文字を書くときは、外部にスクリプトファイルやスタイルファイルを用意するようにしましょう。
< | |
& | |
]]> | |
-- |
これは、XHTMLで <SCRIPT> や <STYLE> の仕様が変更になるのを考慮してのことです。XHTML1.0 C.4 に記述されています。
-- が含まれているために、全体をコメントで囲むようなテクニックも危険なものになっていることに注意してください。XHTML以外ではこの警告は減点されません。
156. <SCRIPT>～</SCRIPT> 内にコメントを書くと、本当にコメントとして扱われます。 *3*
XHTMLでは <SCRIPT> や <STYLE> の内容が #PCDATA です。コメントはコメントとして解釈されてしまうので、旧来のテクニックは使えません。外部にスクリプトファイルやスタイルファイルを用意するようにしましょう。
157. <SCRIPT> タグがありますが、<NOSCRIPT> タグがありません。 *4*
HTMLのヴァージョンによっては、<SCRIPT> に対して <NOSCRIPT> がない場合にこの警告が出ます。
この警告は、WAIで守らなければならない事柄とされています。<NOSCRIPT> はあとから追加されたので、Mozilla2.0などの一部の古いWWWブラウザでは <SCRIPT> はサポートするけども <NOSCRIPT> をサポートしていないことがあります。このようなときは、スクリプトが有効なときでも <NOSCRIPT> 内が表示されてしまうことに注意してください。
また、WAIに示されているのは、重要な情報や機能を持っているスクリプトに対して <NOSCRIPT> を用意しなさいということです。実際にはONCLICKなどの表示を伴わないイベント処理に使われることも多く、これに対する <NOSCRIPT> が必要かというと、必ずしもそうとは言えません。というわけで、この警告はWAIで必須とされているにもかかわらず減点されません。
158. <TITLE> の内容は 64文字以内に収めるようにしましょう。 *3*
仕様上は文字数制限などないのですが、あまり長いタイトルはWWWブラウザによってちょん切られることがあるそうです。しかし、最低でも 64文字は可能なように、とのお達しがRFC1866(J)にあります。HTML4.01(J)にはこのような記述は見当たりません。
159. <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 5 では、スタイルシートの内容まではチェックできません。
<BODY style="background: #FFFF00">
などとしている場合は、チェックできません。
160. <BODY> で BACKGROUND 属性を指定したときは BGCOLOR 属性も指定するようにしましょう。 **
<BODY> で背景画像を指定してあるとき、そこに書かれている文字はその背景画像上でうまく読めるように選ばれているはずです(意図的に背景に溶け込ませることもありますけど)。このとき、BGCOLOR属性を指定していないと、WWWブラウザが画像を表示しない設定などになっていると、その文字が読めなくなってしまう可能性があります。
161. <TAG ATTR> の色指定が <TAG BGCOLOR> の色と同じです。 *3*
例えば、
<BODY background="hogehoge.gif" bgcolor="#FFFFFF" text="#FFFFFF">
のような場合、背景画像の読込みでうまく文字が読めるようになるのでしょうが、背景画像を表示しない(できない)環境では、文字が全く読めなくなってしまいます(意図的に読めなくしていることもありますけど)。警告は、背景画像の指定とは無関係に行なわれます。また、
<BODY bgcolor="#FFFFFF">
<TABLE bgcolor="#FF0000">
<FONT color="#FFFFFF">
のような指定は、読むことができません。
162. <TAG ATTR> の色指定と <TAG BGCOLOR> の色は明度差または色差が不十分です。 *3*
背景色と前景色の明度差または色差が不十分です。 ここでは、Techniques For Accessibility Evaluation And Repair Tools にある方法で明度差、色差が十分か判定しています。それは次のような方法です。
- 背景色、前景色のRGB値を 0～255で表現し、ぞれぞれ R、G、B としたとき、明度を ((R×299) + (G×587) + (B×114)) / 1000 で計算します。
- 背景のRGB値を Rb、Gb、Bb とし、前景のそれを Rf、Gf、Bf としたとき、色差を abs(Rb-Rf)+abs(Gb-Gf)+abs(Bg-Bf) で計算します。
ここで、前景と背景の明度差が 125未満のとき、または色差が 500未満のときにコントラスト不足として警告されます。
神崎正英氏の「色の組み合わせをチェックしてみる」が役に立つでしょう。
背景画像との関係や、スタイルシート中での色はチェックできません。
163. <TAG ATTR> の色指定と <TAG BGCOLOR> の色は輝度比が不十分です。 *3*
背景色と前景色の輝度比が不十分です。 ここでは、Web Content Accessibility Guidelines 2.0 にある方法で輝度比が十分か判定しています。それは次のような方法です。
- 背景色、前景色のRGB値を 0～1.0で表現し、ぞれぞれ R、G、B としたとき、Rに対して R' = (R <= 0.03928)? R/12.92: ((R+0.055)/1.055)2.4 を計算します。G、B に対しても同様です。
- 輝度を R'×0.2126 + G'×0.7152 + B'×0.0722 として求めます。
- 背景色、前景色の輝度の大きい方をL1、小さい方をL2としたとき、 (L1+0.05)/(L2+0.05) として輝度比を求めます。
ここで、レベルAAでは 4.5以上の輝度比が、レベルAAAでは 7以上の輝度比が必要とされています。 ただし、WCAGにあるように、大きいテキストのときなどの例外は処理していません。 また、背景画像との関係や、スタイルシート中での色はチェックできません。
164. <TAG> の ID 属性の値 `XXXX` は NN行目ですでに使われています。 *5*
各タグに付けることのできるID属性は、ひとつのHTML中で重複した名前を付けることはできません。また、ID属性の値は、HTMLでは大文字小文字区別されません。XHTMLでは区別されます。
165. NN行目で参照されている <TAG> の ATTR 属性の ID `XXXX` は定義されていません。 *5*
HTML4.01での <LABEL> のFOR属性などの値は、他のタグのID属性として指定されていなければなりません。
NTT DoCoMo iモードでは、<A IJAM> で指定したIDが、<OBJECT ID> に対応していなければなりません。
166. <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については警告されません。
167. <TAG> の直後に空白以外のテキストを書くことはできません。 *3*
<FIELDSET> の直後には普通のテキストが書けることになっていますが、ここには空白以外を書くことはできません。これはDTD中にコメントされています。次はHTML4.01のDTDからの引用。
#PCDATA is to solve the mixed content problem,
per specification only whitespace is allowed there!
168. <INPUT TYPE="RADIO"> に CHECKED 属性が指定されていますが、NN行目ですでに指定されています。 *5*
<INPUT type="radio"> で、同じ名前のラジオボタン、つまり同じグループのラジオボタンに付けられるチェックはひとつだけです。
169. どの <INPUT TYPE="RADIO" NAME="YYYY"> にも CHECKED 属性が指定されていません。 *3*
同じグループのどの <INPUT type="radio"> にもチェックが付いていません。
HTML4.01(J) では、どれかひとつにチェックを付けた方がよいとされています。
170. どの <OPTION> にも SELECTED 属性が指定されていません。 *3*
同じ <SELECT> 内のどの <OPTION> にもSELECTED属性が付いていません。
HTML4.01(J) では、どれかひとつにSELECTEDを付けた方がよいとされています。
171. <OPTION> に SELECTED 属性が指定されていますが、NN行目ですでに指定されています。MM行目の <SELECT> に MULTIPLE 属性を指定してください。 *5*
<OPTION> に複数のSELECTED属性を付けるには、<SELECT> タグでMULTIPLE属性を指定しなければなりません。
NTT DoCoMo iモード 1.0では、複数SELECTED属性を指定することはできません。
172. ひとつの <SELECT> 中に指定できる <OPTION> は 20件までです。 *5*
NTT DoCoMo iモード 1.0では、<OPTION> による選択肢は20件までが指定可能です。
173. <TAG> には初期値となるテキストを指定しておきましょう。 *3*
<INPUT type="text"> や <TEXTAREA> には、何か初期値となるようなテキストをあらかじめ書いておくことがWAIで薦められています。その理由に、空だと正しく処理できないWWWブラウザの可能性が示されています。
175. <BUTTON> に用いる <IMG> には USEMAP 属性を指定することはできません。 *5*
HTML4.01(J)では、<BUTTON> にイメージを貼り付けるとき、それをイメージマップにすることはできないことになっています。ISMAP も同様です。
176. <TAGA> をここに書くことはできません。NN行目の <LABEL> 内には MM行目に <TAGB> が含まれています。 *5*
フォームコントロールをラベル付けするには何通りか方法がありますが、<LABEL> の要素にフォームコントロールを直接含めてしまうやり方があります。このとき、<LABEL>～</LABEL> 内には、ひとつのコントロールしか含めることができません。HTML4.01(J)を見てください。
177. FOR 属性の含まれない <LABEL>～</LABEL> 内にはフォームコントロールを指定しなければなりません。 *5*
<LABEL> はフォームコントロールに付加属性を付けるためのもので、どれかひとつのフォームコントロールと関連付けられていなければなりません。その方法は、<LABEL> の要素に指定する方法と、FOR属性によってフォームコントロールのID属性と関連付ける方法があります。つまり、FOR属性のない <LABEL> は、要素の内容にフォームコントロールを含んでいなければなりません。
178. <TAG> の ID 属性の値と NN行目の <LABEL> の FOR 属性の値が食い違っています。 **
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.
<LABEL> の要素にフォームコントロールを書いたとき、そのフォームコントロールはその <LABEL> に関連付けられることになっていますが、そこにさらにFOR属性やID属性を指定したときにどのように解釈されるのかについて、HTML4.01(J)には言及がありません。
考えられる組み合わせは次のようになります。
- FORもIDもない場合
仕様上は問題なさそうですが、多くのWWWブラウザ(MSIE5～6、Netscape3～7、Opera6など)では、このラベルはフォームに関連付けられないようです。<LABEL>
<INPUT>
</LABEL> - FORだけある場合
ラベルが他の ID="A" を持つフォームコントロールと関連付けられると思われ、そうすると内容に書かれたフォームコントロールはラベルに関連付けられなくなり、好ましくないと思われます。<LABEL for="A">
<INPUT>
</LABEL> - IDだけある場合
フォームコントロールは外側のラベルと、他の FOR="A" を持つラベルに関連付けられます。ひとつのフォームコントロールに複数のラベルを関連付けることは間違っていません。<LABEL>
<INPUT id="A">
</LABEL> - FORとIDがあって一致する場合
冗長ですが問題ないと思われます。<LABEL for="A">
<INPUT id="A">
</LABEL> - FORとIDがあって食い違っている場合
ラベル要素としてフォームコントロールを書いている意味がなく、好ましくないと思われます。<LABEL for="A">
<INPUT id="B">
</LABEL>
この解釈は間違っているかも知れません。support@heartcore.co.jpまでご指摘ください。
179. <TAG> には TABINDEX 属性を指定するようにしましょう。 *3*
アクセス性向上のために、フォームコントロールの <INPUT>、<TEXTAREA>、<BUTTON>、<SELECT> にはTABINDEX属性を付けて入力順序を指定するようにWAIで薦められています。この警告は減点されません。
WAIには、<A> にも条件付でTABINDEX属性を付けるように書かれていますが、ここでは除いています。
180. <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属性を指定するときの組み合わせは次のようになります。
- どちらにも指定されていない場合
どちらかにACCESSKEY属性を指定しなければなりません。<LABEL>
<INPUT> - ラベルにだけある場合
問題ありません。<LABEL accesskey="A">
<INPUT> - フォームコントロールにだけある場合
問題ありません。<LABEL>
<INPUT accesskey="A"> - 両方にあってキーが一致する場合
冗長ですが問題ないと思われます。<LABEL accesskey="A">
<INPUT accesskey="A"> - 両方にあってキーが食い違っている場合
どちらのキーでもそのフォームコントロールにフォーカスを移すことができるようになるのかも知れません。正しくない指定なのかも知れませんが、とりあえず警告されません。<LABEL accesskey="A">
<INPUT accesskey="B">
181. <TAG> には TITLE 属性を指定するようにしましょう。 *3*
アクセス性向上のために、<ABBR>、<ACRONYM> には、TITLE属性を書くようにWAIで薦められています。
この警告は減点されません。<FRAMESET> や <FRAME> に関しては、書かなければならないとされていて、違う警告が出ます。
182. <OBJECT> には等価な内容を書くようにしましょう。 *4*
<OBJECT> には、次のように要素の内容に適当な説明を書くように求められています。
<OBJECT data="magnifyingglass.gif" type="image/gif">Search</OBJECT>
これは、アクセス指針技術文書4.7.1(J)や4.8.1(J)にあります。
183. <APPLET> に ALT 属性と等価な内容の両方を書くことは薦められていません。 *3*
<APPLET> は <OBJECT> と同じように、要素の内容に適当な説明を書くように求められています。しかし、<APPLET> にはALT属性があるので、内容説明に加えてALT属性で説明を書くと、WWWブラウザはどちらを採用していいのかわかりません。つまり、どちらか一方にするように、アクセス指針技術文書4.8.1(J)に書かれています。
<APPLET> は、HTML4.01では薦められないタグであることにも注意してください。
184. <TAG> の ALT 属性に空白だけの文字列を指定することは薦められていません。 *3*
アクセス指針技術文書5.6.1(J)には、空白だけのALTを指定して、イメージを表示しないときにうまく隙間が空くようにした次のようなのはだめ、と書かれています。
my poem requires a big space<IMG src="10pttab.gif" alt="
">here
Another HTML-lint 5 では、このような語の途中での指定だけでなく、常にチェックされます。
185. <TAG> には ALT 属性を指定するようにしましょう。 *4*
イメージが表示できないWWWブラウザも数多く存在します。また、表示ができるWWWブラウザでも、自動的にはイメージを読みに行かないような設定にしてあることもよくあります。そのようなとき、そこにどのようなイメージが貼り付けてあるのか、適切なコメントがあると、表示されたテキストがぐっと読み易くなります。どのようなコメントが適切かは多くの人がいろいろな意見を述べていますが、宗教色の濃い議論もあるので注意が必要です。ここでは、特に指針は示しませんが、空の指定 alt="" も、それなりに有効な場合があることだけは覚えておいてください。WAIの解説(J)を参照してください。
<IMG> 以外でも、この警告は出ますが、ALT属性はHTML4.01ではほとんど必須属性です。
<INPUT type="image"> はイメージのボタンを作ります。ところがこのタグにはALT属性がありませんでした。HTML4.0でようやくALT属性が指定できるようになりました。
この警告は、アクセス性向上のために、WAIで守らなければならない事柄とされています。
186. <TAG> には WIDTH と HEIGHT 属性を指定するようにしましょう。 *
イメージのサイズを指定しておくと、WWWブラウザが実際にそのイメージを読みに行かなくても、他のテキスト部分のレイアウトを行なうことができます。これは、ネットワークの負荷を軽減し、迅速な表示が行なえることを意味します。
<INPUT type="image"> はイメージのボタンを作ります。ところがこのタグにはWIDTHやHEIGHT属性がないので、どうしてもイメージの読み込みが起こります。HTML4.01にもありません。
プロバイダ指定の <IMG> を利用するアクセスカウンタCGIなどの中には、イメージの幅が特定できないものもあります。当然そのような場合にはWIDTHを指定することはできません。いや、指定してもいいですが、イメージがゆがむかも知れません。
この警告は減点されません。
187. <IMG> には ISMAP と USEMAP 属性の両方を指定することはできません。 *3*
ISO/IEC 15445 では、<IMG> にISMAPとUSEMAPの両方を指定してはならないと明記されています。HTML4.01などにこのような記述はないのですが、両方指定するのはおかしいので、どのHTMLでも警告されます。
188. <IMG ISMAP> でのサーバサイドイメージマップは使わず、クライアントサイドイメージマップを使いましょう。 *4*
サーバサイドイメージマップを使っていると音声出力などでいろいろ不便があったりするため、クライアントサイドイメージマップを利用するようにWAIで強く薦められています。
189. <TABLE> には SUMMARY 属性を指定するようにしましょう。 *3*
アクセス性向上のために、<TABLE> には、SUMMARY属性を使って要約を付けておくことがWAIで薦められています。
ISO/IEC 15445 では必須属性となっていて、違う警告が出ます。
190. <TH> には ABBR 属性を指定するようにしましょう。 *3*
アクセス性向上のために、<TH> には、ABBR属性を使ってヘッダラベルの省略形を付けておくことがWAIで薦められています。ただ、もともと省略形の内容の場合など、闇雲にABBRを付けるのは無意味なのですが、そのような識別が Another HTML-lint 5 ではできません。この警告は減点されません。
191. <COL> を要素に持つ <COLGROUP> には SPAN 属性を指定すべきではありません。 *3*
HTML4.01(J)には、<COL> を要素に持つ <COLGROUP> のSPAN属性は無視される、とあります。
ISO/IEC 15445 ではさらに厳しく、禁止されています。
192. <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"のセルが重なり合っています。
193. <FRAMESET> タグがありますが、<NOFRAMES> タグがありません。 *3*
フレーム機能をサポートしていないWWWブラウザも多いため、<NOFRAMES> を指定して、そういうWWWブラウザの便宜をはかってあげましょう。<NOFRAMES> を間違ったところに書いていたりスペルミスをしていないかもチェックしましょう。特に、<NOFRAME> と S が抜けていることが多いようです。
とはいえ、<NOFRAMES> があればいいというものでもありません。文法的には非の打ち所がないのですが、
<NOFRAMES>
<BODY>
<P>このページは Netscape で見て下さい。</P>
</BODY>
</NOFRAMES>
などというおばかなことはしないようにしましょう。このようにメッセージされても、その人が指示に従えるとは限りません。
194. <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 5 はこれが自分と同じかどうかを判定できません。
195. <FRAME> の SRC 属性で直接イメージなどを指定することは薦められていません。 *4*
<FRAME SRC> でイメージなどを直接指定することは、WAIでは行なわないようにとされています。アクセス指針技術文書4.10.4(J)は、FRAMEにはHTML文書を、ということなんで、HTML以外を指定することは避けましょう。
この警告は、URIが存在するかどうかチェックしているときのみ有効です。
196. <FRAME> には TITLE 属性を指定するようにしましょう。 *4*
アクセス性向上のために、<FRAMESET> や <FRAME> には、TITLE属性を必ず書くようにとWAIに書かれています。
197. <TAG> の ATTR 属性のフレームターゲット名 `XXXX` は NN行目ですでに指定されています。 **
フレームターゲットに同じ名前を付けることはできません。でも、HTML4.01にそのことが書いてあるんでしょうか。
198. <TAG> の ATTR 属性のフレームターゲット名 `XXXX` は予約されています。 *3*
HTML4.01(J)では、次のフレームターゲット名が予約されています。
- _blank
- _self
- _parent
- _top
このような名前を付けることはできません。というか、一般に付けられる名前の制限はもっときついです。次の警告を見てください。
199. <TAG> の ATTR 属性のフレームターゲット名 `XXXX` は小文字で書いたほうが安全です。 **
フレームターゲット名の大文字小文字は区別されないことになっています。したがって、
<FRAME target="_top">
と
<FRAME target="_TOP">
は、同じはずなのですが、一部のWWWブラウザは異なるターゲットとみなしてしまいます。予約されているフレームターゲットは小文字で書くようにしましょう。
200. <TAG> の ATTR 属性のフレームターゲット名 `XXXX` は正しくありません。 *3*
HTML4.01(J)には、フレームターゲット名は英字から始まらなければならない、そうでない名前は無視される、と書かれています。これは、かなり厳しい制約で、将来増えるかも知れない(_topなどの)予約名に対処するためのものだと思われます。しかし、Mozillaなど、HTML4.0に先行してフレームを実装していたWWWブラウザではこのようなことはないようです。
201. <TAG> は物理的フォントタグです。論理的タグを使うようにしましょう。 *3*
文字フォント修飾のタグには、物理的なものと論理的なものがあります。物理的なものというのは、太字の <B> のように直接的なもので、論理的なものというのは、強調の <EM> という意味的なものです。SGMLの精神からは、なるたけ意味的な表現をするように心がけましょう、といったところなんですが、なかなかそうもいきませんね。WAIでも使わないように薦められています。この警告は減点されません。
顔文字などを <TT>:-)</TT> などと書くことも多いでしょう。このようなのはASCIIアートと呼ばれていて、WAIでは複数行に渡るようなASCIIアートは飛び越せるような工夫が必要とされています。
Laura Lemay のHTML本では、<B> が多用されています。
202. <P> は段落のためのタグです。改行するタグは <BR> です。 **
<P> を行末に書いているときにこの警告が出ます。<P> は改行するためのタグではありません。<P> を行末に書いていたのは、HTML2.0より前の大昔のことです。RFC1866(J)では段落のためのタグとして、終了タグを伴って定義されています。
かなり多くの参考書が、<P> を改行するためのタグだとか、1行空けるためのタグだとか紹介しています。それは嘘です。そんなことを堂々と書くような著者は信用してはいけません。自分では調べもせず、間違いの書かれた二次文献や三次文献などからの引用で済ませているからだと思われます。
203. <BR> が多数連続しています。 **
文書構造を無視して整形目的で <BR> を利用しているようなとき、<BR> が頻繁に連続して現れます。この警告を回避するために <BR> <BR> などというお馬鹿なことはくれぐれもしないようにしましょう。
また、Lynxなどの一部のWWWブラウザは、連続する <BR> をひとつにまとめてしまうことがあります。
204. NN行目の <PRE> 内にはタブを書かないようにしましょう。 *3*
<PRE>～</PRE> 内にタブ文字を書くことは避けるように、HTML4.01(J)で強く要請されています。タブ文字は空白文字に置き換えられて表示されるのが普通ですが、モノによって期待通りの結果を得られないことがあるというのが理由です。つまり、<PRE> の整形済みという主旨に反するということです。
205. <Hn> が NN行目の <Hm> に続いていますが好ましくありません。 *3*
HTMLには、章や節を直接表現する構造はありませんが、見出し用のタグ <H1>～<H6> が用意されています。本来、これらの出現順序関係については、何の制約もありません。この警告は、<H2> の次に <H4> が来たら何かおかしいんじゃないの、という程度のものですが、このような使い方はRFC1866(J)では推奨されていません。
また、これらを文字サイズ調整の意味に使っていたりするのを防ぐ効果も多少あります。多くの参考書が、<Hn> を文字サイズ調整のタグだと紹介しています。それは嘘です。ついでに、<Hn> は、ヘッダ(header)ではありません。見出し(heading)です。これも参考書がよく間違っています。
この警告は、アクセス性向上のために、WAIで守るべき事柄とされています。
206. <Hn>～</Hn> 内の <IMG> の ALT 属性には何か説明を書きましょう。 **
見出しにイメージだけが指定されていて、次のようにALT属性が空のときに警告されます。
<H1><IMG src="introduction.png" alt=""></H1>
このようなイメージに対して、<A>の場合はWAIで指摘されているのですが、見出しに対して特に何か言われているわけではありません。しかし、<A>の場合と同じように好ましくないのには変わりないでしょう。
207. <A> には ACCESSKEY 属性を指定するようにしましょう。 *3*
<INPUT> などに対する同様の警告を見てください。この警告は減点されません。
この警告は <A> に対するもので、他方はそれ以外に対するものです。<A> を別扱いしているのは、WAIでも「重要なリンクに対して
」というただし書きが付いているからで、全部の <A> に対してACCESSKEY属性を要求するものではないからです。Another HTML-lint 5 は、どれが重要なリンクかを判断できません。
208. リンクとリンクの間は適当な文字で区切りましょう。 *3*
アクセス性向上のために、リンクとリンクの間は、何か印字可能な文字(空白でもよい)で区切ることが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>
のようにします。
209. リンクイメージの <IMG> の ALT 属性には何か説明を書きましょう。 *3*
リンクに使われているイメージで、次のようにALT属性が空のときに警告されます。
<A href="routes.html"><IMG src="topo.gif" alt=""></A>
このようなイメージには、WAIで何か等価な説明を書くようにとされています。
210. <IMG> の ALT 属性の値 `D` はあまり薦められません。LONGDESC 属性を利用しましょう。 *3*
D-リンクと呼ばれるこの技術は、旧式であまり薦められません。詳しくはアクセス指針技術文書3.2.2(J)や4.7.2(J)を参照してください。
211. <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>
212. <A> のアンカーとして `ここ` などを使うのは好ましくありません。 *3*
アクセス指針技術文書4.6(J)などによれば、例えば、目の不自由な方がページを読むとき、リンク部分だけを拾って読んだりすることがあるそうです。そのようなとき、
詳しくは<A href="detail.html">ここ</A>をクリックしてね
Click <A href="info.html">here</A> for more info.
とかいったリンクでは、意味がわかりません。もっと意味のある文章にしましょう。「ここ」だけじゃなくて「こっちのサイト」とか「このページ」とかいうのも引っかかります。一部の代表的なものしか引っかかりませんが、意図しないものも引っかかってしまうかも知れませんので、そのようなときは support@heartcore.co.jp までお知らせください。
なぜこのようなのがよくないかは、Laura Lemay のHTML入門や、Style Guide for online hypertext(J) などに書いてあります。WAIでもこのような書き方は薦められていません。これは、HERE症候群と呼ばれています。
また、「クリック」というリンクもよくないとされています。なぜなら、リンクをたどる動作はクリックとは限らないからです。「押す」という用言も同様です。
213. <A> のアンカーとして <IMG> の ALT 属性の値に `ここ` などを使うのは好ましくありません。 **
アンカーに画像を使った場合、画像の内容を表しているALT属性に「ここ」などを指定した場合も HERE症候群とみなします。
214. <A> のアンカー名 `XXXX` 中に空白文字が含まれています。 *3*
アンカー名にはどんな文字を使ってもいいことになっているのですが、まあ、空白は使わない方がよかろう、ということです。アンカー名に安全でない文字を使った場合も参照してください。
HTML4.01(J)では、どんな文字でも使っていいわけではなくなりました。
215. <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属性での指定は廃止されました。
216. <A> のアンカー名が空です。 **
アンカー名を指定したつもりが
<a href="http://www.uso800.ac.jp/fake.html#">
となってるときに出る警告です。"#" の後ろの名前がありません。
217. <A> のアンカー名 `XXXX` は NN行目にもありました。 *5*
ひとつのHTML中で同じ名前を何個所にも付けることはできません。
<A name="girl">こばやしちよじ</A>
<A name="girl">きくちさよこ</A>
というのは正しくありません。次の警告も見てください。
218. <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属性にしようという思惑から、あえて指摘しているのだと思われます。
219. <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以上以外では警告されません。
220. <A> のアンカー名 `XXXX` は NN行目で ID 属性として定義されています。 *
<A href="#HOEE">
に対応するアンカーを、ID属性で指定してもいいことになっています。 つまり、このリンクに
<H1 id="HOEE">
のようなのが対応してもいいのです。しかし、古いWWWブラウザの実装ではこのような対応はあまり実現できていないようです。
XHTML1.0(J)ではNAME属性でなくてID属性を使うように薦められており、XHTML1.1ではそのようなNAME属性は廃止されています。
HTML4.0以外では警告されません。この警告は減点されません。
221. <A> の NAME 属性の値 `XXXX` と ID 属性の値 `YYYY` は、同一タグ中では同じでなければなりません。 *5*
<A name="HYOEE" id="HYOEE">
のように、同一タグ中でのNAME属性とID属性の値は同じでなければならないとされています。HTML4.0以上以外では警告されません。XHTML1.1では、このようなNAME属性は廃止されています。
222. <TAG> には NAME 属性と ID 属性の両方を指定するようにしましょう。 *3*
アンカー名の指定は、NAME属性ではなくID属性で行なう方向にW3Cは移行させています。
ISO/IEC 15445 や
XHTML1.0(J)(Appendix C.8)では過渡的な措置として、どちらでもうまくいくように、両方を指定しておくように薦めています。ただし、同じ値を書かなければなりません。過渡的なものなので、XHTML1.1ではそのようなNAME属性は廃止されています。
223. <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値は大文字に変換されるため、大文字で参照する必要があります。
224. <A> のアンカー名 `XXXX` が見つかりませんでした。 *3*
リンクを
<A href="#shit">
と書いたとき、このアンカーはそのHTML中に存在しなければならないのですが、これが見つからないときに警告されます。名前は大文字小文字が区別されるので注意してください。
225. <A> のアンカー名 `XXXX` は参照されていません。 *
指定されているアンカー名が同一のHTML中で参照されていないからといって、それが誤りとはいえません。ただ名前を付けているだけかも知れませんし、別のHTMLから参照されているかも知れないからです。しかし、名前の大文字小文字を間違っていたり、スペルミスなどがないとはいえません。この警告は減点されません。
226. <TAG> の ATTR 属性の URI が空です。 **
つまり、
<IMG src="">
なんて書くのはちょっと、ということなんですが、RFC1808によると、URIが空の場合は <BASE> で指定されているURIと同じとみなすように書かれています。<BASE> がないときは自分自身と同じなので、そのとき
<A href="">
とした場合は、自分自身にリンクしていることになるのですが、Mozillaなどではそのような効果を期待することはできないようです。それどころか、JavaScriptとの組み合わせで、
<A href="" onClick="this.href=pickupRandomURL()" onMouseOver=...>
なんていうサンプルまであります。
227. <TAG> の ATTR 属性の URI `XXXX` 中に空白文字が含まれています。 *3*
URIに空白を含めることは禁止されていませんが、安全ではありません。URI中では空白は %20 として表現します。
228. <TAG> の ATTR 属性の URI `XXXX` 中に `\` が含まれています。パスの区切りは `/` でなければなりません。 **
URIではディレクトリ階層を示す区切りは "/" です。Windowsなどの "\" は "/" に置き換えましょう。
229. <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には半角のチルダは含まれておらず、上線(￣)となっています。
この警告は、以前のようにチェックできるようにするもので、減点されません。
230. <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 なら安全だ、などと書かれていますが、∠ という実体参照も定義されているので、ちっとも安全ではありません。ついでに、ℑ、≠ という実体参照もキーワードと競合します。いずれにしても、パラメタ区切りを "&" のまま書くからいけないので、"&" と書けばどんな場合も安全です。
231. <TAG> の ATTR 属性の URI 中の実体参照 `&xx;` は使用できない文字 `X` です。 *3*
URI中に実体参照を用いて
<A href="<where>">
なんて書いても、これは "<where>" と書いたのと等価です。つまり、< や > などはURIに使えない文字なので、< や > などもURIには使えません。どうしても < や > などを書きたければ、
<A href="%3Cwhere%3E">
のようにします。&image のように、CGI呼び出し中の & に続くパラメタが、たまたま定義されている実体参照と同じだった場合にもこの警告が出ることがあります。CGI呼び出し中のパラメタ区切りは & と書くようにしましょう。
ÿ のような文字参照も同様です。このとき、含まれる # はアンカー名との区切り文字とはみなされません。
232. <TAG> の ATTR 属性の URI `XXXX` 中に ASCII以外の文字が含まれています。 *5*
URIに使用できる文字は、ASCII コード 20～7E の文字だけです。漢字やカタカナなどは使用できません。
233. <TAG> の ATTR 属性の URI に指定されているスキーム名 `XXXX` は正しくありません。 *5*
URIに指定できるスキーム名は、英小文字、数字、プラス "+"、ピリオド "."、ハイフン "-" から成る、とRFC2396に書いてあります。英大文字についてはそれを小文字とみなしてもよいとも書いてあります。この警告は、これらに違反したときに出ます。
234. <TAG> の ATTR 属性の URI のスキーム名 `XXXX` は小文字で指定しましょう。 **
URIに指定するスキーム名に使える文字には、本当は英大文字は含まれていませんが、RFC2396では、大文字を小文字とみなすような融通を利かしてもよいと書いてあります。
235. <TAG> の ATTR 属性の URI に不明のスキーム名 `XXXX` が指定されています。 **
URIに指定できるスキームに何があるのかをすべて把握しているわけではありません。いくつかのRFCにあるものなどを拾ってありますが、これらに含まれないスキーム名のときこの警告が出ます。もし、正しいのに警告されるときは support@heartcore.co.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 などを見てください。
236. <TAG> の ATTR 属性の URI `XXXX` はインタネット上から参照できないかも知れません。 **
インタネット上に公開するHTML中のURIに、file: などのローカルファイルを指すスキームを指定しても、そのファイルを参照することはできません。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
237. <TAG> の ATTR 属性の URI のスキーム `XXXX` は利用できません。 *3*
TTNet ドットi では、利用できるスキームは http: mailto: tel: だけです。
238. <TAG> の ATTR 属性の URI に指定されているスキーム `javascript` の利用は薦められていません。 *3*
URIに"javascript"を使うのは、利用者がスクリプトを使わない環境のときなどのことを考えて、使用を慎むように、アクセス指針技術文書4.12.1(J)に書かれています。しかし、実際には必ずしも制限される必要のない javascript スキームも少なからず存在します。例えば、javascript が動作すれば恩恵を被るものの、動作しなくてもなんら支障のないような場合などです。この警告は減点されません。
239. <TAG> の ATTR 属性の URI `XXXX` は正しくない書式です。 *3*
URIの格好はRFC2396で決められていますが、これは総括的な一般URIの構文を規定しているだけで、個々のスキームごとの構文を規定しているわけではありません。ここでは、RFC1738などで決められている次のスキームについて個別のチェックを行ないます。このチェックに違反するとこの警告が出ます。
http://host[:port]/path[?query][#fragment-id]ftp://[user[:passwd]@]host[:port]/pathfile://[[user[:passwd]@]host[:port]]/pathgopher://host[:port][/type[selector[%09query[%09string]]]]mailto:user@domain[?name=value]news:[article@]domainnntp://host[:port]/newsgroup[/article]telnet://[user[:passwd]@]host[:port][/]wais://host[:port]/[database]prospero://host[:port]/path[field]
ただし、上記構文はかなり端折ってあり、正確ではありません。本当はそれぞれもっといろいろな書き方があります。正確な構文等を知りたいときは以下を参照してください。ただし、Another HTML-lint 5 ではRFC1738以外が必ずしも反映されているわけではありません。また、RFC2396には、これらの修正情報があります。
- RFC822 (MAILTO)
- RFC959 (FTP)
- RFC977 (NNTP)
- RFC1036 (NEWS)
- RFC1436 (GOPHER)
- RFC1625 (WAIS)
- RFC1945 (HTTP1.0)
- RFC2068 (HTTP1.1)
- RFC2141 (URN)
- RFC2368 (MAILTO)
- RFC2396 (Generic Syntax)
個々のスキームごとに使用できる文字が微妙に異なっていますが、URIで表記するときにRFC2396で禁じられている文字を、直接書いたり実体参照などを用いて表現したりすることはできません。このような文字は、すべて %3C のように表現しなければなりません。
いくつか間違った例を示しましょう。
http:~k16/hogehoge.html
http:/~k16/hogehoge.html- 相対指定のURIに
http:などのスキーム名を付けることはできません。http:は付けないようにします。
- 相対指定のURIに
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.htmlhttp:にユーザIDやパスワードを含めることはできないことになっています。しかし、一部のユーザエージェントはこれを受け付けています。安全のためには、URI中に素のパスワードなどは書かないようにしましょう。ftp:などには構文上含められます。
http://www.uso800.ac.jp/cgi-bin/hogehoge.cgi?foo=bar|zoo=penguin- CGIのパラメタ区切りに
|が用いられています。|はURIに使えない文字なので%7Cと表記しなければならないのですが、残念ながら、そうすると動作しないCGIが多数存在します。Muquit氏のアクセスカウンタ (Count.cgi) に関してURIに使えない文字の解説を見てください。
- CGIのパラメタ区切りに
http: //www.uso800.ac.jp/- スキーム名の後ろに空白が含まれています。URIの最後とかに余計な空白が入っているときも同様です。空白を%20と書いているときはこの限りではありません。
file://c:/homepage/index.html
file://c:\homepage\index.html- Windowsなどのローカルのファイル名をそのままURIとして利用することはほとんどの場合できません。ローカルホストをアクセスするためには、ホスト名を
localhostとするか空にする必要があります。また、WindowsやDOSのディレクトリ区切り\は使えないので/に置き換えます。Macintoshのディレクトリ区切り:も/に置き換えます。 -
file://localhost/c:/homepage/index.html
file:///c:/homepage/index.html -
file:///c%7C/homepage/index.html
:を|に置き換えることもあるようです(これの出典はどこですか? support@heartcore.co.jp までお教えください)。しかし|はURIに使えない文字なので%7Cと表記します。- Windowsなどのローカルのファイル名をそのままURIとして利用することはほとんどの場合できません。ローカルホストをアクセスするためには、ホスト名を
mailto:geregere.uso800.ac.jp- ユーザ名とドメイン名の区切りは
@です。 -
mailto:geregere@uso800.ac.jp
- ユーザ名とドメイン名の区切りは
mailto:ｇｅｒｅｇｅｒｅ＠ｕｓｏ８００．ａｃ．ｊｐ- 全角文字で宛先などのURIを記述することはできません。
mailto:Killer Panther <geregere@uso800.ac.jp>- mailto: URI は、RFC1738では、単一の宛先だけを含むように書かれていましたが、RFC2368によって、(RFC822ではphraseと呼ばれる)宛名を含めたり、複数の宛先を列挙したりできるように拡張されました。これをHTML中で記述するためには注意が必要です。URI中に書けない文字はすべて%20のように書かなければなりません。
-
mailto:Killer%20Panther%20%3Cgeregere@uso800.ac.jp%3E -
mailto:いしの <k16@uso800.ac.jp> -
mailto:k16 @ uso800 . ac . jp
mailto:は、他の(http:などの)スキームと異なり、直ちにこのURIによってメールが送信されたりすることはありません。WWWブラウザがこのURIの情報を解釈してメーラに渡し、メーラを利用者が操作して(本文などを書いてから)メールを送信することになります。このため、mailto:URIの書式にはかなり自由度のある実装がされていると思われます。
また、RFC822によると、各語の切れ目に任意の空白を入れられるので、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.jp
news:uso800@192.168.0.1
本来の目的とは無関係に、mailto: などの後ろに文章を書くという裏技(?)が存在するようです。これは、Mozillaなどでマウスを持って行くとステータスラインにその文章が表示されるという効果を狙ったものだと思われます。
240. <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 5では調べていないので、このような場合の警告を出すことができません。ここでは
http://www.uso800.ac.jp/%7Ek16
http://www.uso800.ac.jp/~k16
というような場合にだけ警告が出ます。アカウント名のプレフィクスは、指定で ~ 以外にもなるんだけど、まあ、多くは ~ だろうということです。
URIが存在するかどうかチェックしているときには、実際に "/" が必要かどうかがチェックされることがあります。現在はURI取得の方法にLWPを使った環境でのみ可能です。
また、
http://www.uso800.ac.jp
というのは誤りではありません。このホスト名の指定だけの場合は "/" を省略してもいいことになっています(RFC1738、RFC1808)。
241. <TAG> の ATTR 属性の URI `XXXX` はうまく評価されないかも知れません。 **
// で始まるURIは、正しいURIです。しかし、これはWWWブラウザによっては正しく評価されないかも知れません。
242. <TAG> の ATTR 属性の URI `XXXX` は NN行目で `YYYY` と指定されています。 *
例えば、
http://www.uso800.ac.jp/bogus/
というURIと、
http://www.uso800.ac.jp/bogus
というURIが指定されている場合、"/" のある方とない方とどちらかが間違いなのが明白です。この警告はこのようなとき出ます。http/https スキームについてだけ調べています。
なーんて、浅知恵で考えていましたが、実際には "/" のありなしでまったく異なるリソースを指すことが可能です。
とは言っても、そのような設定をされているサーバがそんなに多いとも思えないので、この警告自身は残しておきますが、減点されません。
243. <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
は同じリソースを指すとみなしています。こんなことはしないと思っていたら、(同じリソースを指すという前提で)存外にすることがあるようです。
244. <BASE> の HREF 属性で指定するより前に NN行目で相対 URI が指定されています。 *5*
<BASE> でHREF属性を指定するときは、それより前に相対URIを用いて外部との関連付けを行なってはなりません。
HTML4.01(J)では、一切の参照を制限しています。HTMLかどうかなど、リソースの種類についての限定は行なっていないことに注意してください。しかし一方で、<BASE> は相対URIに対してのみ効果のあることも書かれています。Another HTML-lint 5 では、<BASE> 以前に出現する相対URIについてのみ警告します。
245. <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">
のようにする必要があります。
246. </HTML> の後にまだ何かテキストがあります。 *6*
HTMLは </HTML> が現れたらおしまいです。WWWブラウザによっては </HTML> の後も表示しますが、そんなのを期待してはいけません。
247. XXXXXX では、HTML文書は NKバイト以内でなければなりません。 *5*
NTT DoCoMo の iモード用のHTML文書は2Kバイト(2.0では5Kバイト)以内に、J-SkyWeb用のHTML文書は6Kバイト以内に、それぞれ収めなければなりません。このバイトサイズには、ページ中で使用されているイメージファイルのサイズも含まれるのですが、通常はそこまでは加算してのチェックはされません。URIが存在するかどうかチェックしているときには加算されます。
248. <IMG> の SRC 属性の URI `XXXX` が YYY ではありません。 *5*
NTT DoCoMo の iモード用のHTML文書に利用できるイメージはGIFのみです。さらに iモード 1.0 では２階調GIFのみの対応なのですが、調べたGIFが２階調かどうかはチェックされません。
また、J-SkyWeb用のHTML文書に利用できるイメージはPNGのみです。
この警告は、URIが存在するかどうかチェックしているときのみ有効です。
249. <TAG> の入れ子が深過ぎます。<UL>、<OL> の入れ子は 3階層以内でなければなりません。 *5*
J-SkyWeb用のHTMLでは、<UL>、<OL> の入れ子は 3階層までしか許されていません。
250. <TAGA> 中に指定できる <TAGB> は NN個までです。 *5*
J-SkyWeb用のHTMLでは、<UL>、<OL> 内に書ける <LI> は 99個までしか許されていません。
NTT DoCoMo の iモード 4.0用のHTMLでは、<OBJECT> 内に書ける <PARAM> は 16個までしか許されていません。
252. XXXXXX は Shift JIS で記述しなければなりません。 *5*
特許出願用文書は Shift JIS で書かなければならない決まりです。覚え書きを見てください。また、NTT DoCoMo の iモード 用のときも Shift JIS で書かなければなりません。覚え書きを見てください。
HTMLをURLでなく、DATA領域に指定した場合は、このエラーはチェックされません。
253. XXXXXX では `■` を使うことはできません。 *5*
特許出願用HTMLに使える文字については、くどくどいろいろ細かい決まりがあるのですが、とりあえず、利用者使用禁止となっている文字だけチェックしています。また、使える文字として半角カタカナや、丸付き数字の一部などが追加されています。覚え書きを見てください。
255. 不適格な属性値 *9*
有効な属性値を期待
例えば
AREAタグのCOORDS属性は以下の規則に従わなければならない：
-
shape = "rect" & coords = 長方形の座標 # #
イメージマップ上のこのハイパーリンクの領域の形状は長方形であることを明記する
値:コンマで区切られた４つの整数のリストで、以下の順番に正確に従う:- CSSピクセルにおけるイメージの左端から長方形の左側への距離を表す整数
- CSSピクセルにおけるイメージの上端から長方形の上面への距離を表す整数
- CSSピクセルにおけるイメージの左端から長方形の右側への距離を表す整数で、このリストの最初の整数値より大きい
- CSSピクセルにおけるイメージの上端から長方形の底部側への距離を表す整数で、このリストの２番目の整数値より大きい
-
shape = "circle" & coords = 円の座標 # #
イメージマップ上のこのハイパーリンクの領域の形状は円形であることを明記する
値:コンマで区切られた３つの数字のリストで、以下の順番に正確に従う:- CSSピクセルにおけるイメージの左端から円の中心への距離を表す整数
- CSSピクセルにおけるイメージの上端から円の中心への距離を表す整数
- CSSピクセルにおける円の半径を表す非負の整数
-
shape = "poly" & coords = 多角形の座標 # #
イメージマップ上のこのハイパーリンクの領域の形状は多角形であることを明記する
値:少なくとも６つの整数から成り、その各々をコンマで区切ったリストで、リスト中の整数の数は偶数（すなわち整数の数は６ま
256. 不適格なMIMEタイプ *9*
MIMEタイプのシンタックス：
2616で定義されているメディアタイプ； すなわち一般的には、必要とされるタイプ、続いて"/"、続いて必要とされるサブタイプ、任意で１つかそれ以上の";"のインスタンス、続いてパラメータ。 例）text/css, text/css;charset=utf-8.
257. 不適格なLANGコード *9*
期待されている有効な言語コード ： RFC 5646 言語タグはハイフンで区切られたアスキー英数字サブタグで構成される。最短のISO 639 言語コード（例： 英語はen）や正確さを加える追加的なサブタグにより自然言語を特定する主要タグがある。最も一般的な追加的サブタグタイプは２文字のISO 3166国コード（例：GBが英国）である地域サブタグである。IANAは許容されるサブタグのレジストリを保持している
259. 要素はコンテクスト中で許されていない *9*
要素はコンテクストの規則に従うことを期待されている
例えば:
- STYLE要素は、SECTION要素中にある場合、以下の規則に従わなければならない : STYLE要素はフローコンテンツに続く。
- 要素SOURCEは、このコンテクスト中で要素(AUDIO/VIDEO)の子にはなれない
260. PROGRESS要素には無効な属性値 *9*
PROGRESS要素のVALUE およびMAX属性は以下の規則にしたがわなければならない:
- VALUE属性の値はMAX属性の値以下でなければならない
- VALUE属性の値はMAX属性が指定されていないとき０以下でなければならない
261. 要素は指定された条件下では 'A/BUTTON' の下位要素にはなれない *9*
要素はコンテクストの規則に従うことを期待されている
例えば:
- 属性USEMAPを持つ要素IMGはA/BUTTON要素の下位要素にはなれない
- 値が'TOOLBAR'の属性タイプを持つ要素MENUはA/BUTTON要素の下位要素にはなれない
- 属性CONTROLSを持つインタラクティブ要素VIDEOはA/BUTTON要素の下位要素にはなれない
266. コンテクスト中で許されない属性 *9*
例えば:
COMMAND要素のRADIOGROUPおよびCHECKED属性は以下の規則に従わなければならない:
- COMMAND要素は、TYPE属性の値が'COMMAND'のとき、RADIOGROUPまたはCHECKED属性を保持してはならない
- COMMAND要素は、TYPE属性の値が'CHECKBOX'のとき、RADIOGROUP属性を保持してはならない
267. METER要素には不適格な属性値 *9*
METER要素のVALUE、MIN、LOW、HIGH、OPTIMUMおよびMAX属性は以下の規則に従わなければならない：
- min属性の値はvalue属性の値以下でなければならない
- value属性の値はmin属性が指定されていないとき０以上でなければならない
- value属性の値はmax属性の値以下でなければならない
- value属性の値はmax属性が指定されていないとき０以下でなければならない
- min属性の値はmax属性の値以下でなければならない
- max属性の値はmin属性が指定されていないとき０以上でなければならない
- min属性の値はmax属性が指定されていないとき０以下でなければならない
- min属性の値はlow属性の値以下でなければならない
- low属性の値はmin属性が指定されていないとき０以上でなければならない
- min属性の値はhigh属性の値以下でなければならない
- high属性の値はmin属性が指定されていないとき０以上でなければならない
- low属性の値はhigh属性の値以下でなければならない
- high属性の値はmax属性の値以下でなければならない
- high属性の値はmax属性が指定されていないとき１以下でなければならない
- low属性の値はmax属性の値以下でなければならない
- low属性の値はmax属性が指定されていないとき１以下でなければならない
- min属性の値はoptimum属性の値以下でなければならない
- optimum属性の値はmin属性が指定されていないとき０以上でなければならない
- optimum属性の値はmax属性の値以下でなければならない
- optimum属性の値はmax属性が指定されていないとき１以下でなければならない
268. 有効な参照を期待 *9*
要素は以前から存在するフィールドへの有効な参照を持つことを期待されています
例えば:
INPUT要素のLIST属性は以下の規則に従わなければならない：
- input要素のlist属性はdatalist要素を参照しなければならない
CONTEXTMENU属性（HTML5のグローバル属性）は以下の規則に従わなければならない：
- CONTEXTMENU属性はMENU要素を参照しなければならない
269. このHTMLバージョンでは未サポートのタグ *9*
適切な要素および／またはCSSを使用してください。tt要素がキーボード入力のマークアップに使われるところでは、kbd要素を考慮してください； 変数にはvar要素を検討してください； コンピュータコードには、code要素を考慮してください； そしてコンピュータアウトプットには、same要素を検討してください。同様に、もし大きな要素が見出しを示すために使われているならば、h1要素の使用を考慮してください； もしも重要なメッセージをマークアップするために使われているならば、強い要素を考慮してください； そしてもしも参照用のテキスト反転表示に使われているならば、mark要素を考慮してください
270. FRAME, FRAMESET & NOFRAMESタグはこのバージョンのHTMLでは未サポート *9*
IFRAME およびcssを使うか、統合されている様々な不変パーツとともに完全なページを生成するためにサーバー側の includesを使用してください
291. PROFILE属性はHTML5ではHEADタグ内で未サポート *9*
宣言に用いられるとき、ドキュメント中でどのMETA項目が使われるかは不要です； 完全に削除し名称を登録してください。特定のユーザーエージェントのビヘイビアを始動させるには、LINK要素を使用してください
294. LONGDESC属性はHTML5ではIFRAME/IMGタグ内で未サポート *9*
記述にリンクするために正規の A要素を使用してください。または（イメージの場合）そのイメージからイメージの記述へのリンクを提供するためにイメージマップを使用してください
295. LOWSRC属性はHTML5ではIMGタグ内で未サポート *9*
２つの別々のイメージを使用するのではなく（SRC属性中で与えられている）プログレッシブJPEGイメージを使用してください
298. ARCHIVE/CLASSID/CODE/CODEBASE/CODETYPE属性はHTML5ではOBJECTタグ内で未サポート *9*
プラグインを呼び出すために DATA および TYPE 属性を使用してください。特にこれらの名前でパラメータをセットするために PARAM要素が使用可能です
306. ABBR属性はHTML5ではTD/THタグ内で未サポート *9*
明白で簡潔に始まるテキストを使用し、複雑なテキストはその後に含めてください。TITLE属性はより複雑なテキストを含む点において有用で、セルのコンテンツを簡潔にすることができます
308. DATASRC/DATAFLD/DATAFORMATAS属性はHTML5では未サポート *9*
スクリプトやページをダイナミックに追加するXMLHttpRequestのようなメカニズムを使用してください
