Google

jweblint 97がサポートするwarning一覧


ここに掲げたのは、 jweblint 97 v0.12がサポートするwarningの一覧です。 これらのwarningは、 全てconfiguration fileやコマンドラインオプションで、 チェックするかどうかを個別に設定することができます。

Identifierの後ろにenabledとあるものは、 デフォルトで有効になっています。 disabledとなっているものは、 デフォルトでは無効です。 後ろに[EXPERIMENTAL]と書かれているものは、 ベースとなったWeblint v1.017に、 新たに実験的に加えられた機能であることを表しています。 これらは将来変更・削除されることがあります。

warningについて、 何故そのような警告を出すのか簡単な説明を付けておきましたので、 参考にしてください。 どんなwarningがあるのか、 そして何故そのようなwarningを出すのかよく理解して、 お好み通りに設定してご利用ください。


属性値のデリミッタに ' を使うのは全てのブラウザでサポートされてはいません (ABC タグの XYZ 属性).

Identifier: attribute-delimiter (disabled)

  • RFC 1866によれば、 属性値はシングルクォート (') またはダブルクォート (") で囲むことになっていますが、 実際にデリミッタとしてシングルクォートが使えるブラウザはあまり多くありません。 ポータビリティを考えれば、 常にダブルクォートを使うようにした方が良いでしょう。

    参照: RFC 1866 の "3.2.4. Attributes"

XXXAAA 属性の値が不正です (...).

Identifier: attribute-format (enabled)

  • 例えば <BODY BGCOLOR="FFFFFF"> など、 属性値のフォーマットが間違っていると、このように警告されます (この例の場合、"#FFFFFF" とすべき)。

"..." は不明な実体参照です.

Identifier: bad-entity (enabled) [EXPERIMENTAL]

  • &lt;&gt; のような実体参照 (entity reference) は、 大文字・小文字を区別します。従って、 &LT;&GT; のように書くのは間違いです。 これを &lt;&gt; と同じように解釈してしまうuser agentもあるようですが、 間違った実装です。 これらの誤った実体参照が使われていると、 不明な実体参照であるとして警告します。

    KNOWN BUG

    URL中に `&' が出てくる場合 (例: <A HREF="foo.cgi?bar=baz&qux=quux">) などは、 用法としては正しいのですが、 jweblint 97 はこれも不明な実体参照として警告してしまいます。 申し訳ありませんが、このような場合は警告を無視するか、 うるさければチェックを無効にしてください。

アンカー "..." のターゲットが見つかりませんでした.

Identifier: bad-link (disabled)

  • ローカルなリンクに限ったチェックですが、 このwarning-identifierを有効にしておくと、 リンク先のファイルが存在するかどうか検証することができます。

<...> はテキストにとって不正な文脈です; XXX の中にあるべきです.

Identifier: bad-text-context (enabled)

  • 例えば、UL エレメントのすぐ後にテキストがあるのは、 HTMLドキュメントの構造としておかしな文脈です。 UL や OL などのリストエレメント内では、 テキストは LI エレメント内になければなりません。
    同様に、TABLE エレメント内では、 テキストは TD や TH エレメント内にあるべきです。

<BODY> はあっても <HEAD> がありません.

Identifier: body-no-head (enabled)

  • 厳密に言えば、HTMLの文法上、<HEAD> は必須ではありません。 しかし、 どこまでがヘッダ情報でどこからが本文なのか構造上明らかにするためにも、 ヘッダは <HEAD> で、 本文は <BODY> できちんと囲っておくべきです。

終了タグ <...> には何らの属性も指定してはなりません.

Identifier: closing-attribute (enabled)

  • タグに対する属性は、常に開始タグに指定します。 終了タグは属性を指定するものではありません。

組合わせエレメント ... 内の 先頭に/末尾に 空白文字があります.

Identifier: container-whitespace (disabled)

  • 一般に、HTMLドキュメント中の空白文字の位置はあまり重要ではありませんが、 例えばリストエレメント (<LI>) 中の先頭に空白文字があると、 リストの先頭が他と揃わずに不格好な表示になります。

    また、アンカーエレメント (<A> ... </A>) の中は通常下線などで強調表示されますが、 この先頭や末尾に空白文字があると、 下線が前後にはみだしてみっともないことになります。 アンカーとしてイメージを使っている場合などは特にそうです。

directoryindex file がありません (index.html).

Identifier: directory-index (enabled)

  • URLとしてディレクトリが指定された場合、 通常 index.html など (サーバの設定により異なる) のドキュメントが表示されますが、 そのディレクトリに index.html がない場合、 ディレクトリ内のファイルリストが表示されてしまいます。 各ディレクトリには、 indexとなるファイルを置いておいた方が良いでしょう。

選択された拡張 `...' は DOCTYPE 宣言と一致しません.

Identifier: doctype-mismatch (disabled) [EXPERIMENTAL]

  • DOCTYPE宣言は、そのHTMLドキュメントがどのヴァージョンのHTMLの仕様に従って書かれているかを明らかにするものです。 従って、-x オプションなどでHTML拡張を指定する場合は、 指定した拡張とDOCTYPE宣言とが一致しているべきです。

    このwarning-identifierが有効になっていると、 指定された拡張と、DOCTYPE宣言の記述との整合性をチェックします。 例えば、DOCTYPE宣言で

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

    のようにHTML 3.2が指定されているのに、

    jweblint -x Netscape foobar.html

    のようにNetscape拡張が指定された場合、 選択された拡張とDOCTYPE宣言とが一致しない旨を警告します。 DOCTYPE宣言がない場合は、 HTML 2.0が指定されたものとみなします。

    なお、jweblint 97では、 DOCTYPE宣言でどのヴァージョンのHTMLに従うか書いておけば、 自動的に対応する拡張を認識するようになっています。 -x オプションなどでいちいちHTML拡張を指定するより、 適切なDOCTYPE宣言を書いておくことを強くおすすめします。

    参照: require-doctype

XX 行目の </...> は, YY 行目に開始された <...> と重なり合っているようです.

Identifier: element-overlap (enabled)

  • タグは一般にネストすることができますが、タグが互い違いになっていると、 正しく処理されない場合があります。タグをネストするときには、 一番最後にある開始タグを最初に閉じるようにしましょう。

組合わせエレメント <...> が空です.

Identifier: empty-container (enabled)

  • <P>...</P> や <A>...</A> のようなエレメントは、 <P> ならばパラグラフ、<A> ならばアンカー文字列など、 何らかの内容を囲むために使われます。
    これらを中に何も含まない空の状態で用いるのは、正しくない使い方です。

<...> には属性の指定が必要です.

Identifier: expected-attribute (enabled)

  • 一般には、タグの属性は必ず指定しなければならない、 というわけではありませんが、例えば <A> のようなエレメントは、 HREFNAME といった属性を指定して、 はじめて意味を持ちます。 これらのタグでは、必ず何らかの属性を指定すべきです。

<...> の `...' 属性は拡張マークアップです (これを許すには "-x <extension>" を使ってください).

Identifier: extension-attribute (enabled)

  • jweblint 97では、 デフォルトの仕様は HTML 2.0 に準拠しています。 HTML 3.2 で追加された属性など、 拡張されたマークアップを使いたい場合は、 -x オプションでどの仕様に従うか、 明示的に指定してください。

    -x オプション等で指定したにもかかわらずこの警告が出る場合は、 そのマークアップは指定された拡張には含まれない、 他の拡張に含まれる属性であることを示しています。 どの拡張にも含まれない属性に対しては、 不明な属性である旨の警告が表示されます。

    なお、jweblint 97では、 DOCTYPE宣言でどのヴァージョンのHTMLに従うか書いておけば、 自動的に対応する拡張を認識するようになっています。 適切なDOCTYPE宣言を書いておくことを強くおすすめします。

    参照: unknown-attribute, require-doctype

<...> は 拡張マークアップです (これを許すには "-x <extension>" を使ってください).

Identifier: extension-markup (enabled)

  • extension-attribute同様、 拡張されたマークアップを使いたい場合は、 -x オプションで指定するか、 使いたい拡張に応じた適切なDOCTYPE宣言を書いておく必要があります。

    -x オプションやDOCTYPE宣言で指定したにもかかわらずこの警告が出る場合は、 そのマークアップは指定された拡張には含まれない、 他の拡張に含まれるエレメントであることを示しています。 どの拡張にも含まれないエレメントに対しては、 不明なエレメントである旨の警告が表示されます。

    参照: unknown-element, require-doctype

`file' URL はホスト限定の scheme です (...).

Identifier: file-url (enabled) [EXPERIMENTAL]

  • RFC 1738 によれば、 file URL schemeは特定のホストコンピュータにおいてアクセス可能なファイルを指定するもので、 Internet上で普遍的にアクセス可能なリソースを指定するものではありません。 従って、Intranetなど、 ローカルな環境でのみ用いるのであればこれでもいいかもしれませんが、 Internetにおいて一般に公開するWebページにこれを用いるのはふさわしくありません。 HTMLエディタなどでリンクを設定すると、 file URL schemeを使ってリソースを指定するものがあるので、 注意が必要です。

    このwarning-identifierが有効になっていると、 file URL schemeが使われていたら警告します。

    参照: RFC 1738"3.10 FILES"

<...> は HEAD エレメント内でのみ使うことができます.

Identifier: head-element (enabled)

  • TITLE, NEXTID, LINK, BASE, META といったタグは、 HEAD 内でのみ使うことができるエレメントです。 これらのタグを使う場合は、HEAD で囲んでおくべきです。

<H?> を <A> の中に入れるのではなく, <A> を <H?> の中に入れるべきです.

Identifier:heading-in-anchor (enabled)

  • <A NAME="xxx"><H1>Heading</H1></A>

    のような書き方より、

    <H1><A NAME="xxx">Heading</A></H1>

    の方が望ましい書き方です。 HTML 2.0 の DTD にもその旨の記載があります。

    参照: RFC 1866 の "9.1. HTML DTD"

おかしなヘディングです - 開始タグは <H?> ですが, 終了タグは </H?> です.

Identifier: heading-mismatch (enabled)

  • 当たり前ですが、<H1>Heading</H2> のように、 開始タグと終了タグのレベルが対応していないのはおかしなヘディングです。 ヘディングの開始タグと終了タグは必ず同じレベルのものを使ってください。

良くないスタイルです - ヘディング <H?> が XX 行目の <H?> に続いています.

Identifier: heading-order (enabled)

  • ヘディングは見出しのレベルを示すものであって フォントのサイズなどを示すものではありませんから、 例えば <H1> の次に <H3> が出てきたりするのはおかしな使い方です。 RFC 1866 でも、 この様な使い方はすべきでないと明記されています。

    参照: RFC 1866 の "5.4. Headings"

アンカーとして `here', `ここ', `これ', `こちら' 等を使うのは良くない形式です!

Identifier: here-anchor (enabled)

  • `here' や `ここ' のような内容のない文字列をアンカーとして使用しても、 リンクそのものに関する情報は何も提供してくれません。 これは、特にアンカー文字列をインデックスとして使用するサーチエンジンが 数多くあることを考えると、良くない書き方と言わざるをえません。

    こういうのはhere症候群という病気だそうです :-)

一番外側のタグは <HTML> .. </HTML> であるべきです.

Identifier: html-outer (enabled)

  • HTMLドキュメントの構造として、まずDOCTYPE宣言を書き、 次に <HTML> .. </HTML> でドキュメント全体を囲むのが望ましい書き方です。 実際には、<HTML> はHTMLの文法上は省略可能で、 多くのuser agentはこのタグがなくても問題なく処理してくれます。

    しかし、例えば複数のHTMLドキュメントをまとめてデータベースに格納している場合など、 各ドキュメントが <HTML> .. </HTML> で囲まれていれば、 必要なドキュメントだけを抜き出すのが容易になるなど、 再利用性を向上させることができます。

    また、国際化に対応した HTML 2.x (RFC 2070) などでは、 <HTML LANG="ja-JP"> のように LANG 属性を指定して、 そのHTMLドキュメントがどの言語で書かれているかを示すことができます。 その意味でも、 構造を明らかにするために <HTML> を書いておくべきです。

エレメント <...> は組になって使われません -- </...> は不正です.

Identifier: illegal-closing (enabled)

  • <IMG> や <INPUT>、 <OPTION> などのエレメントは単独で用いられるタグで、 終了タグはありません。これらのタグに終了タグをつけるべきではありません。

    ただし、よく誤解されますが、 <P> は <P> .. </P> のように、 原則として組になって使われるべきタグです (終了タグは省略可能)。 <P> は段落の最後ではなく、段落の最初に書くべきです。

IMG に ALT テキストが定義されていません.

Identifier: img-alt (enabled)

  • IMG タグに ALT テキストが定義されていないと、 Lynxなどのテキストベースのuser agentではイメージを見ることができないので、 そのイメージが一体何を表しているのかわかりません。 視覚障害者が音声出力端末で利用する場合なども同様です。 特に、そのイメージがアンカーとして使われている場合は、 何にリンクされているのか全くわからないことになってしまいます。

    イメージを表示できるグラフィカルなブラウザでも、 イメージがロードされるまでの間 ALT テキストを表示したり、 イメージをロードしない設定にしておくと代わりに ALT テキストが表示されるものもありますので、 IMG には必ず意味のある ALT テキストを定義しておくようにしましょう。 装飾的な意味しかないイメージであれば、 ALT="" などとして、 イメージの痕跡を消してしまいましょう。

IMG タグに WIDTH 及び HEIGHT 属性を設定することで, 幾つかのブラウザでの見栄えを向上させることができます.

Identifier: img-size (disabled)

  • HTML 2.0の仕様にはありませんが、 HTML 3.2などでは、 IMG タグに WIDTH 及び HEIGHT 属性でイメージのサイズを指定しておくことで、 イメージをロードするまでの間、 そのイメージが表示されるスペースを確保しておくことができます。 また、イメージをロードしない設定にしていても、 レイアウトが崩れてしまうのを防ぐことができます。

"<" と "...>" の間に空白文字を入れてはいけません.

Identifier: leading-whitespace (enabled)

  • 開始タグの中では、 エレメント名と `>' の間には空白文字を入れることができますが、 `<' とエレメント名の間には、空白文字を入れてはいけません。

    参照: RFC 1866 の "3.2.4. Attributes"

メタキャラクタ '...' は '...' で表されるべきです.

Identifier: literal-metacharacter (enabled)

  • `>' のようなメタキャラクタを文中にそのまま書いてしまうと、 user agentが誤って解釈してしまうおそれがあります。 メタキャラクタは `&gt;' のように、 実体参照 (entity reference) を使って表すべきです。

タグ <...> が小文字ではありません.

Identifier: lower-case (disabled)

  • HTMLのタグは、大文字で書いても小文字で書いても構いません。 しかし、好みでタグを大文字や小文字に統一して書きたい場合もあるでしょう。 このwarning-identifierを有効にしておくと、 タグが小文字でなかった場合に注意を促すことができます。

    参照: upper-case, mixed-case

HEAD の中に <LINK REV=MADE HREF="mailto..."> が見つかりませんでした.

Identifier: mailto-link (disabled)

  • LINK タグに REV=MADE と書いておくことで、 そのHTMLドキュメントの作者に関する情報を含めることができます。 このように HREF 属性を使ってページ作者のメールアドレスを書いておくと、 Lynxなどのuser agentでは、 そのアドレス宛に、メールでコメントを送ったりすることができます。

コメント中に埋め込まれたマークアップは幾つかのブラウザを混乱させることがあります.

Identifier: markup-in-comment (enabled)

  • HTMLの文法上は、コメント中にマークアップを含んでいても構いません。 しかし、歴史的な理由で、 `>' が出てくるとコメントの終了と解釈してしまう実装も存在します。 正しく実装していない方が悪いのですが、混乱を避けるためには、 コメント中にはマークアップを含まない方が安全です。

    参照: RFC 1866 の "3.2.5. Comments";
    unclosed-comment, unterminated-comment

たとえ PRE エレメントの中であっても, '...' の代わりに '...' を使うべきです.

Identifier: meta-in-pre (enabled)

  • <PRE> .. </PRE> の中では、 整形済みのテキストがそのまま表示されますが、 <A> や <EM> といったタグは使うことができます。 マークアップとの混同を避けるためにも、たとえ PRE の中であっても、 `>' などのメタキャラクタは `&gt;' のように実体参照を使って表すべきです。

</...> がつり合いません (マッチする <...> が見つかりません).

Identifier: mis-match (enabled)

  • 終了タグに対応する開始タグがないと、このように警告されます。 タグの囲む範囲が大きくなってくると、 ついつい対応がおかしくなってしまうことがあります。

    特に UL や OL のようなリストエレメントを幾重にもネストしている場合、 うっかり開始タグと終了タグの対応がおかしくなってしまうことがあるので、 注意が必要です。

タグの case (大文字・小文字) が無視されています.

Identifier: mixed-case (enabled)

  • HTMLのタグは、大文字で書いても小文字で書いても構いません。 従って、このwarning-identifierが有効になっていても、 いちいち警告が表示されることはありません。

    ただし、jweblint 97では、 好みでタグを大文字や小文字に統一して書きたい場合に、 その旨の注意を促すよう設定することもできます。

    参照: lower-case, upper-case

<...> は <...> の直後に続かなければなりません.

Identifier: must-follow (enabled)

  • 例えば <HEAD> は <HTML> の直後に、 <BODY> は </HEAD> の直後に表れねばなりません。 これらの間に別のタグやテキストがあった場合、上記のように警告されます。

<...> はネストすることはできません -- XX 行目の <...> に対応する </...> が見つかりません.

Identifier: nested-element (enabled)

  • <A> や <FORM> のようなエレメントは、 ネストすることができません。 特に <A> をネストしていると大きな混乱を引き起こすので、 そのような使い方をしてはなりません。

非 ASCII 文字 "..." があります.

Identifier: non-ascii (disabled) [EXPERIMENTAL]

  • HTML 2.0 (RFC 1866)では、 HTMLドキュメントに使える文字は公式にはISO-8859-1 (Latin-1)で定義されたものに限られていました。 しかし、現実には、 他の言語を表現するために様々な文字集合・符号化方式 (エンコーディング) が使われてきました。 それらはおおむね、 7 bit部分はUS-ASCIIと互換性がありますが、 8 bit全てを使った部分には互換性がないのが普通です。

    HTMLの国際化規格であるRFC 2070がリリースされたことにより、 扱える文字集合はISO/IEC 10646-1:1993 UCS-4 with implementation level 3に規定されたもの、 と飛躍的に拡大されましたが、 符号化方式については特定のものに限定されてはいません。 そのため、異なる符号化方式で表示しようとすると、 意図したものとは異なる文字が表示されてしまうことがあります。

    例えば、ISO-8859-10xA9の文字はcopyright記号ですが、 ISO-8859-20xA9の文字は caron付き S (LATIN CAPITAL LETTER S WITH CARON) です。 また、ISO-8859-1で書かれたドキュメントをEUC-JPとして表示しようとすれば、 やはりおかしなことになります。

    結局、どの環境でも確実に読めるようにしたければ、 US-ASCIIのみを使って書いておくのが安全です。 このwarning-identifierを有効にしておくと、 ドキュメント中に非 ASCII 文字を使っていないかチェックすることができます。 ただし、判定は1バイトごとに行ないますので、 複数バイト文字が含まれているとおかしな表示になります。

<...> は HEAD エレメント内で使うことはできません.

Identifier: non-head-element (enabled)

  • HEAD エレメント内で使えるタグは、 TITLE, LINK, META, BASE など、いくつかのものに限られています。 BODY エレメント内で用いるような通常のタグを、 HEAD 内で使ってはいけません。

<...> は一般にはもう使用されていません.

Identifier: obsolete (enabled)

  • PLAINTEXT, XMP, LISTING といったタグは、 過去との互換性のために残されてはいるものの、すでに廃れたタグです。 新たなドキュメントを書くときにこれらのタグを使うべきではありません。

<...> エレメント内に対になっていない引用符があります.

Identifier: odd-quotes (enabled)

  • 属性値を囲む引用符は、必ず対になっていなければなりません。 特に、<A HREF="foobar.html> .. </A> のように、 アンカータグ内の属性値を囲む引用符が対になっていないと、 多くのuser agentでは大変おかしなことになりかねないので、 注意すべきです。

タグ <...> は1つだけ使われるべきです. XX 行目に1つ見られました!

Identifier: once-only (enabled)

  • HTML, HEAD, BODY, TITLEといったドキュメントの構造を表すタグは、 1ドキュメント中に1つしか使うことはできません。 TITLE が複数あったりするのは、完全に誤った書き方です。

<...> は物理的フォントマークアップです -- 論理的マークアップを使ってください (例えば ...).

Identifier: physical-font (disabled)

  • <I> や <B> といった物理的にフォントのスタイルを指定するタグは、 見栄えについては規定しない、 というSGMLの基本精神からすれば良くないタグです。 また、user agentによってはこれらの指定通りに処理できない可能性もあります。 <EM> や <STRONG> のような、 論理的なマークアップを心掛けた方が良いでしょう。

... エレメントの XYZ 属性の値 (ABC) は引用符で囲まれるべきです. (i.e. XYZ="ABC")

Identifier: quote-attribute-value (enabled)

  • 属性値は原則として引用符 (" または ') で囲まねばなりません。 ただし、SGMLの規格では、以下のいずれかの場合に該当する場合は、 引用符を省略しても良いことになっています。

    • 属性値が名前文字のみからなっており、 かつSGML宣言で "SHORTTAG YES" と指定されている場合

    • 属性値が名前文字のみからなっており、 かつ属性値が属性宣言で指定されている場合

    HTMLのSGML宣言では、"SHORTTAG YES" と指定されており、 名前文字としてアルファベットの大文字 (A-Z)・小文字 (a-z)、 10進数字 (0-9)、ハイフン (-)、ピリオド (.) が指定されています。 属性値が名前文字以外の文字を含む場合は、引用符を省略してはなりません。

    例えば、SIZE="+1" のような属性値は、 名前文字以外を含んでいるので、引用符の省略は文法違反になります。 良くわからなければ、 属性値は常に引用符で囲む習慣を付けておいた方が良いでしょう。

<...> エレメント内で XYZ 属性が繰り返されています.

Identifier: repeated-attribute (enabled)

  • 同一のエレメント内で、同じ属性が繰り返して指定されてはなりません。 例えば、<IMG SRC="foo.gif" SRC="bar.gif">のような指定は間違っています。

最初のエレメントが DOCTYPE の記述ではありませんでした.

Identifier: require-doctype (enabled)

  • RFC 1866によれば、 正しい仕様に従ったHTMLドキュメントであることを示すために、 各ドキュメントは必ず

    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

    といったDOCTYPE宣言で始まらなければならないことになっています。

    また、HTML 3.2の仕様でも、 HTML 3.2に従った各ドキュメントは必ず

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

    といったDOCTYPE宣言で始まらなければならない旨が規定されています。 HTMLドキュメントには、 必ず適切なDOCTYPE宣言をつけておきましょう。

    なお、jweblint 97では、 DOCTYPE宣言が書かれていると、 それに応じて適切な拡張を自動的に認識するようになっています。 その意味でも、DOCTYPE宣言を書いておくことを強くおすすめします。

    参照: RFC 1866 の "3.3. HTML Public Text Identifiers", HTML 3.2 Reference Specification"The Structure of HTML documents";
    doctype-mismatch, extension-attribute, extension-markup

HEAD エレメント内に <TITLE> がありません.

Identifier: require-head (enabled)

  • RFC 1866によれば、 全てのHTMLドキュメントは必ず TITLE エレメントを含んでいなければならないことになっています。 HTML 3.2の仕様でも同様です。
    各ドキュメントには、意味のある TITLE をつけておくようにしましょう。

    参照: RFC 1866 の "5.2.1. Title", HTML 3.2 Reference Specification"The Structure of HTML documents"

<...> エレメントには XYZ 属性が必要です.

Identifier: required-attribute (enabled)

  • 多くの属性は必須ではありませんが、 IMG タグの SRC 属性BASE タグの HREF 属性など、 いくつかのエレメントには必須の属性があります。 これらの属性の指定は省略することはできません。

<...> にとって不正な文脈です - <...> エレメント内で使わなければなりません.

Identifier: required-context (enabled)

  • HTMLのドキュメント構造はそれほど厳密ではありませんが、 いくつかのエレメントは、使える文脈が限定されています。 例えば、LI は UL や OL といったリストエレメントの中で使わねばなりませんし、 INPUT や OPTION、TEXTAREA といったエレメントは FORM の中になければなりません。 これらのエレメントが正しい文脈で使われていない場合、警告されます。

HTML の仕様書は TITLE を 64 文字以内に収めることを推奨しています.

Identifier: title-length (enabled)

  • RFC 1866によれば、 TITLE の長さは制限されてはいないものの、 長すぎる TITLE はいくつかのアプリケーションでは 切り詰められてしまう可能性があるため、 64文字以内に収めるべきことが推奨されています。

    実際、多くのuser agentではタイトルバーなどに TITLE を表示するので、 あまり長い TITLE を付けると表示しきれません。 長すぎる TITLE は付けないようにしましょう。

    参照: RFC 1866 の "5.2.1. Title"

アンカー "..." のターゲットは directory です/ではありません -- "..." とすべきです.

Identifier: trailing-slash (disabled) [EXPERIMENTAL]

  • URLがディレクトリを指している場合、 "foo/" のように末尾に `/' を付けておかないと、 無駄なトラフィックを生むことになります。 また、実際は通常のファイルなのに、 "foo.html/" のように誤って末尾に `/' がついていると、 リンクが辿れなかったり、例えそのページに飛べても、 その後のリンクが辿れなくなることがあります。

    このwarning-identifierが有効になっていると、 ローカルなリンクに限ってですが、 これらの正しくない表記に対して警告します。

コメントが閉じられていません (コメントは: <!-- ... -->).

Identifier: unclosed-comment (enabled)

  • 正しいコメントの書式では、コメントは `<!' と `>' の間に、 `--' と `--' で囲って書きます。 従って、コメント宣言の終了を表すには、 コメントを閉じる `--' の後に `>' が続かねばならないのですが、 歴史的な理由から、 `>' のみでコメント宣言の終了と解釈してしまう実装が存在します。 しかし、現在では <!-- comment > のような書き方は間違いであり、 このような書き方をしていると、 コメントが閉じられていないとして警告します。

    参照: RFC 1866 の "3.2.5. Comments";
    markup-in-comment, unterminated-comment

XX 行目の <...> に対応する終了タグ </...> が見つかりません.

Identifier: unclosed-element (enabled)

  • <A> .. </A> のようなタグは必ず開始タグと終了タグのセットで用いられ、 終了タグを省略することはできません。 対応する終了タグが見つからない場合、このように警告されます。

予期せぬ < が <...> にあります -- 閉じられていないエレメントの可能性があります.

Identifier: unexpected-open (enabled)

  • 例えば <IMG SRC="eq1.gif" ALT="a<b"> のように書かれていると、 IMG エレメントが閉じられていないうちに、 新たなエレメントが表れたかのように解釈されてしまうおそれがあります。 このような書き方をするときは、 `<' は `&lt;' のように実体参照で表されるべきです。

<...> エレメントの "..." 属性は不明です.

Identifier: unknown-attribute (enabled)

  • 使われている属性がjweblint 97がサポートするいずれの拡張にも含まれない場合、 このように警告されます。 -x オプションなどで指定した拡張には含まれないが他の拡張には含まれる属性の場合は、 その属性は拡張マークアップである旨の警告がなされます。

    参照: extension-attribute

<...> は不明なエレメントです.

Identifier: unknown-element (enabled)

  • 使われているエレメントがjweblint 97がサポートするいずれの拡張にも含まれない場合、 このように警告されます。 -x オプションなどで指定した拡張には含まれないが他の拡張には含まれるエレメントの場合は、 そのエレメントは拡張マークアップである旨の警告がなされます。

    参照: extension-markup

URL 中に安全でない文字が含まれています (...).

Identifier: unsafe-url (enabled) [EXPERIMENTAL]

  • RFC 1738 によれば、 URLの記述に使えるのは、 US-ASCIIの図形文字のみとされています。 従って、0x00-0x1F, 0x7F の範囲の制御文字や、 US-ASCIIでは使われない、 0x80-0xFFの範囲のコードをURL中に直接記述してはなりません。 これらの文字をURL中に使う場合は、エンコードする必要があります。

    このwarning-identifierが有効になっていると、 上記の範囲の安全でない文字がURL中に使われていると警告します。

    参照: RFC 1738"2.2. URL Character Encoding Issues";
    url-backslash, url-whitespace

コメント宣言中の `--' の対応が不正です.

Identifier: unterminated-comment (disabled) [EXPERIMENTAL]

  • 正しいコメントの書式では、コメント宣言は `<!' と `>' の間に、 `--' と `--' で囲まれたコメントを複数含むことができます。 従って、コメント宣言中の `--' と `--' の対応がおかしいと、 正しく解釈すると、コメント宣言が終了していないとして、 それ以降は全てコメントと解釈されてしまうことになります。

    よくある間違いが、 <!-- -- --><!--------------> のような書き方です。

    例えばLynx 2.6では、 コメントを「正しく」解釈する設定にしておくと、 上記のようなコメント宣言は終了していないと解釈し、 それ以降を表示しなくなってしまいます。

    このwarning-identifierが有効になっていると、 このような `--' の対応が不正なコメントに対して警告します。

    参照: RFC 1866 の "3.2.5. Comments";
    markup-in--comment, unclosed-comment

タグ <...> が大文字ではありません.

Identifier: upper-case (disabled)

  • HTMLのタグは、大文字で書いても小文字で書いても構いません。 しかし、好みでタグを大文字や小文字に統一して書きたい場合もあるでしょう。 このwarning-identifierを有効にしておくと、 タグが大文字でなかった場合に注意を促すことができます。

    参照: lower-case, mixed-case

URL 中に `\' が含まれています -- path の区切りは `/' でなければなりません (...).

Identifier: url-backslash (enabled) [EXPERIMENTAL]

  • RFC 1738 によれば、 URL中に `\' (backslash) を用いるのは安全ではなく、 これを含む場合には必ずエンコードしなければなりません。 また、URLにおいてpathの区切りを表すのは `/' ですが、 にもかかわらず、Windows環境のHTMLエディタなどでは、 file:\\\c:\www\foobar.htm のようなおかしなURLを埋めこんでしまうものがあります。

    このwarning-identifierが有効になっていると、 このようなURL中の不正な `\' の使用に対して警告します。

    参照: RFC 1738"2.2. URL Character Encoding Issues";
    unsafe-url, url-whitespace

watch list にある URL "..." が見つかりました.

Identifier: url-watch (disabled) [EXPERIMENTAL]

  • これは、HTMLドキュメント中にある種のURLを使用していないか、 監視できるようにするための機能です。 どのようなURLを監視するかは完全にユーザの裁量に任されています。 どちらかというとwebmaster向きの機能です。

    監視対象となるURLは、 変数 `url-watch-list' に正規表現で指定します。

URL 中に空白文字が含まれています (...).

Identifier: url-whitespace (enabled) [EXPERIMENTAL]

  • RFC 1738 によれば、 URL中にスペースやタブ、改行といった空白文字を含めるのは安全ではなく、 これらを使う場合は必ずエンコードする必要があります。 特に、長いURLを書いているとつい途中で改行したくなるかもしれませんが、 多くのuser agentでは、 このような空白文字を含んだURLを正しく扱うことはできません。

    このwarning-identifierが有効になっていると、 URL中の空白文字の使用に対して警告します。

    参照: RFC 1738"2.2. URL Character Encoding Issues";
    unsafe-url, url-backslash


石川 雅康 (ISHIKAWA Masayasu)

E-mail: mimasa@aichi-u.ac.jp

jweblintホームページ: http://www.aichi-u.ac.jp/%7Emimasa/jweblint/