- Grammatically wrong *6*
- Correct in grammar but wrong as HTML *6*
- Correct both in grammar and as HTML, but still need to follow WAI and/or technical note. (priority 1) *4*
- Correct both in grammar and as HTML, but not recommended in WAI, techinical note and/or RFC *3*
- Empirically unrecommended **
- Religiously unrecommended *
- Due to programmatic reason
0. Validation is aborted as it has exceeded 999 errors
It is programmed to abort checking if there are so many errors. Some critical errors might be included in the rest of the document, but they will not be detected. If you get many of the similar errors, you may want to exclude those errors from checking. In case exactly the same errors are detected for the same line repeatedly, it should be a trouble in program, so please contact us at support@heartcore.co.jp .
1. URI `XXXX` of <TAG> ATTR attribute does not exist or is inaccessible. **
It checks if the specified URIs actually exist, but is set to timeout after a short period of time (customizable) for better performance . Yet it may take some time for slow response links to have checked. Only http: schemes are checked. Incorrect URI is not to be checked.
You may find digits at the end of the message and the digits are result codes for HTTP requests. The codes are mainly divided into the followings.
| 100s | Notice | |
| 200s | Success | |
| 300s | Moved | |
| 400s | Client Error | |
| 500s | Server Error | |
Among these codes, 400s and 500s are errors. However, only the following codes indicate non-existent or inaccessible resources.
| 403 | Access Forbidden | |
| 404 | File Not Found | |
| 410 | Gone From Server | |
Unauthorized error (401) obviously means the resource does exist, and you are unable to tell if the resource exists in case of Server errors. It is not possible for Another HTML-lint 5 to check grammar of such resources.
You may receive single-digit codes when using httpreq.pl instead of LWP. Those codes are displayed when a error occurs before HTTP request.
| 2 | IP Unavailable | |
| 3 | Unable to access Host | |
| 4 | Time Out | |
With LWP, you get 500s errors when IP is unavailable due to DNS.
Please refer to RFC1945, RFC2068, RFC2616 etc. for details about HTTP status codes.
It is not possible to get correct results when using direct <BASE> through for example JavaScript.
This error is not detected if HTML is specified in DATA area instead of URL.
Please note some of HTTP requets will not be accepted depending on ISP. In that case, you will get errors for all URLs unless "Check as GET request" option is checked.。
2. DOTYPE declaration is not present at the beginning. *3*
HTML includes various versions. DOCTYPE indicates that the document is written in HTML and which version of HTML it is. However, most of the WWW browsers can handle HTML without DOCTYPE declaration. Yet you should write DOCTYPE declaration, even though there is no DOCTYPE supported for MSIE or Mozilla.
DOCTYPE declaratin is written in this way: <!DOCTYPE ～>. Please do not forget "!".
In case of HTML, DOCTYPE will be like this: <!DOCTYPE HTML ～>. The "HTML" in this declaration indicates <HTML> - </HTML> which contains the whole HTML. Another HTML-lint 5 is provided only for HTML.
3. Control characters are included before DOCTYPE declaration. **
Control character(s) is included before DOCTYPE declaration. It might be invisible such as JIS escape code. You may need to investigate it with binary dump etc.
4. Unknown DOCTYPE is declared.
Another HTML-lint 5 currently supports the following DOCTYPEs. Clicking on "Grammar" lists tags for each DOCTYPE. For your information, the lists are not organized so well as they are generated from rulefiles dynamically. "No DOCTYPE for xxx" means there is no public identifier.
Please refer to this website for what DOCTYPE declaratin means. Also, you should be aware that the trailing "EN" just indicates DTD is written in English and does not mean anything about the HTML document. You can not change it to something like "JA" without knowing what it is.
There is no compatibility among most of the HTMLs, for example HTML4.0 is not a HTML which is upward compatible with HTML3.2.
In XHTML, system identifier is required in DOCTYPE declaration.
- HTML1.0 → Grammar
No DOCTYPE for HTML1.0 - HTML2.0(RFC1866) (J) → Grammar
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> - HTML2.x(RFC2070) (J) → Grammar
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN"> - HTML+ → Grammar
<!DOCTYPE HTMLPLUS SYSTEM "HTMLPLUS.DTD"> - HTML3.0 → Grammar
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN"> - HTML3.2 (J) → Grammar
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> - HTML4.0 Strict (J) → Grammar
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> - HTML4.0 Transitional (J) → Grammar
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> - HTML4.0 Frameset (J) → Grammar
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"> - HTML4.0 Mobile (J) → Grammar
<!DOCTYPE HTML SYSTEM "html40-mobile.dtd"> - HTML4.01 Strict (J) → Grammar
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> - HTML4.01 Transitional (J) → Grammar
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> - HTML4.01 Frameset (J) → Grammar
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"> - XHTML1.0 Strict (J) → Grammar
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - XHTML1.0 Transitional (J) → Grammar
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> - XHTML1.0 Frameset (J) → Grammar
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"> - XHTML1.1 → Grammar
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> - XHTML + RDFa 1.0 → Grammar
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> - XHTML Basic (J) → Grammar
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> - XHTML Mobile Profile → Grammar
<!DOCTYPE html PUBLIC "-//OPENWAVE//DTD XHTML Mobile 1.0//EN" "http://www.openwave.com/DTD/xhtml-mobile10.dtd"> - ISO/IEC 15445 → Grammar
<!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 → Grammar
<!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 → Grammar
- Netscape Navigator 3.0 → Grammar
- Netscape Navigator 4.0 → Grammar
No DOCTYPE for Netscape Navigator(Mozilla) - Microsoft Internet Explorer 3.0 beta → Grammar
<!DOCTYPE HTML PUBLIC "-//Microsoft//DTD Internet Explorer 3.0 HTML//EN"> - Microsoft Internet Explorer 3.0 → Grammar
- Microsoft Internet Explorer 4.0 → Grammar
- Microsoft Internet Explorer 5.0 → Grammar
- Microsoft Internet Explorer 5.5 → Grammar
No DOCTYPE for MSIE - IBM WebExplorer 1.1 → Grammar
No DOCTYPE for WebExplorer - Compact HTML → Grammar
<!DOCTYPE HTML PUBLIC "-//W3C//DTD Compact HTML 1.0 Draft//EN"> - NTT DoCoMo imode 1.0 → Grammar
- NTT DoCoMo imode 2.0 → Grammar
- NTT DoCoMo imode 3.0 → Grammar
- NTT DoCoMo imode 4.0 → Grammar
- NTT DoCoMo imode 5.0 → Grammar
No DOCTYPE for NTT DoCoMo imode - NTT DoCoMo imode XHTML 1.0 → Grammar
<!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 imode XHTML 1.1 → Grammar
<!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 → Grammar
- J-SkyWeb Station → Grammar
No DOCTYPE for J-SkyWeb - TTNet doti → Grammar
No DOCTYPE for doti - Patent Application HTML → Grammar
No DOCTYPE for patent application HTML
If you do not find your DOCTYPE here and you know the DTD for it, please contact us at support@heartcore.co.jp so we may be able to add it.
Here are typical mistakes.
<!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">
The first three of them are generated by IBM HomePage Builder and the last one is generated by Internet Explorer 4.0.
5. Case mimatch of public identifier specified in DOCTYPE declaration.*6*
In DOCTYPE declaration, public identifier is case sensitive like "-//W3C//DTD HTML 4.01 Transitional//EN" .
6. DOCTYPE declaration "XXXX" is not supported in Another HTML-lint 5.
This alert is displayed for some DOCTYPE declarations known as unsupported.
7. HTML "XXXX" is a obsoleted HTML and should not be used.*3*
HTML2.0 and HTML3.0 etc. are already obsoleted. You should not used them.
8. HTML4.0 is not a recommended HTML. HTML4.01 should be used instead. *3*
HTML4.0 specified in DOCTYPE declaration is not recommended. You better use HTML4.01 which is the revised version of HTML4.0. This alert does not deduct any point.
9. Specified XXXX deos not match with DOCTYPE declaratin. DOCTYPE declaration will be ignored.
Please ensure a correct DOCTYPE is specified in correct spelling.
10. DOCTYPE declaration must be present at the beginning of the document. *5*
DOCTYPE declaration has to be written at the beginning of the document except comments and XML declaration. That is, it should be present before <HTML>
11. `HTML` in DOCTYPE declaration must be written in lower case. *5*
HTML written in DOCTYPE declaration <!DOCTYPE HTML ～> indicates that the HTML document is enclosed with <HTML>～</HTML>. In XML(J), element name and attribute name are case sensitive. Upper case <HTML> and lower case <html> are read as different things. All of the element names are written in lower case in XHTML1(J) and lower case html should be also written in DOCTYPE declaration.
12. `!doctype` and `public` must be written in upper case. *5*
DOCTYPE declaration has to be written in upper case in XHTML.
13. System identifier is required in DOCTYPE declaration. *6*
System identifier indicates the location of DTD specified in DOCTYPE declaration as below.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTML always requires system identifier.
14. Incorrect system identifier is specified in DOCTYPE declaration. *6*
The specified system identifier is invalid. Public identifiers require particular system identifiers.
15. Case mismatch of system identifier specified in DOCTYPE declaration
System identifier specified in DOCTYPE declaration is case mismatch.
16. <!XXXX ～> which seems to be SGML declaration or DTD declaration will be ignored.
Declarations such as <!SGML ～> and <!ELEMENT ～> are all igonored except DOCTYPE. It does not check if the specified declaration actually exists, so even a fake declaration like <!USO800 ～> will be ignored. The actual declarations are as below.
<!SGML ～> | |
<!DOCTYPE ～> | |
<!ELEMENT ～> | |
<!ATTLIST ～> | |
<!ENTITY ～> | |
<!NOTATION ～> | |
<!SHORTREF ～> | |
<!USEMAP ～> | |
To comment out tags, it should be "<!--IMG ～-->" inseated of "<!IMG ～>".
17. Most of the browsers do not understand marked section <![XXXX[ ～ ]]> .
Marked section is used to define a part of SGML document, for example <![CDATA[ ～ ]]>. However most of www browsers do not understand this format, and neither do Another HTML-lint 5. HTML4.01(J) also says it should not be used.
Marked section includes the followings but these are not to be spell-checked.
<![CDATA[ ～ ]]> | |
<![RCDATA[ ～ ]]> | |
<![IGNORE[ ～ ]]> | |
<![INCLUDE[ ～ ]]> | |
<![TEMP[ ～ ]]> |
In XHTML1(J), some elements such as <SCRIPT> are now #PCDATA instead of CDATA. To write it in the old way, it should be like this:
<script>
<![CDATA[
... unescaped script content ...
]]>
</script>
Another HTML-lint 5 understands only CDATA marked section with HTML4 or newer. Other marked sections are still handled but very roughly with no careful consideration. Please see Notes for details.
Also, please note that it can include blanks like <![ CDATA [, but multiple lines will not be understood.
This alert does not deduct any point.
18. `XX` is not allowed to appear in marked section. *6*
The following strings are not allowed to be used in general marked sections. XML(J)
]]> | |
< | |
& |
The following string is not allowed to be used in CDATA marked section.
]]> |
You are not able to include any script or stylesheet containing these strings, so external scripts and stylesheets are required.
However, Another HTML-lint 5 checks only CDATA marked section with HTML4 or newer and this error never be actually displayed.
19. Marked section <![XXXX[ in the NN line is not closed. *6*
The marked section is not closed. However Another HTML-lint 5 does not pay much attention to where it is closed.
20. XML declaration must be at the beginning of the document. *6*
XML declaration which starts with <?xml has to be present at the beginning of the document. That is, before DOCTYPE declaration.
21. XHTML strongly requires XML declaration. *3*
XHTML1(J) strongly requires XML declaration. E.g.:
<?xml version="1.0" encoding="UTF-8"?>
22. XML declaration must be closed with `?>`. *6*
General SGML processing order is closed with ">", but XML declaration has to be closed with "?>".
23. This XML declaration is incorrect. *6*
Correct XML declaration format is defined in XML(J). Please note the order of attributes are also fixed. Another HTML-lint 5 does not check attribute values in detail except for version="1.0".
24. Processing order `<?～>` can not be understood.
Another HTML-lint 5 does not understand XML(J), so it does not make much sense to check grammar of XML. Actually, "<?" is a mark which indicates some processing order for general system dependence. As HTML4.01(J) says, ">" is generally used to close processing order. "?>" is used to XML declaration.
In older WWW browsers, processing order may be displayed directly. This does not deduct any point.
25. `--` better not be in comment for safety. *3*
Comment in HTML is written as "<!-- ～ -->", but replacing "～" with "--" requires much attention. According to RFC1866(J), anything between "--" and "--" is considered as comment and the pair of them can be present multiple times and only blank characters are allowed to be written between the pairs. In short, the following examples are not correct.
<!----------->
<!-- FOO -- BAR -- BAZ -->
In first example, "--"s are not combined correctly. In the second one, blank characters are not used between the pairs. The followings are correct examples (as RFC1866).
<!------------>
<!-- FOO --
-- QUZ -->
In the upper example, there are twelve "-"s, so they can be combined as pairs.
Another HTML-lint 5 does not check such a strict spec, but does alert if an extra "--" appears. Most of WWW browsers, however, handle these hyphens quite tolerantly.
26. `--` can not be used in comment. *5*
HTML4.01(J) says that multiple sequntial hyphens should not be written in comment. It is also the same in XML(J). That is, the above examples are all wrong.
27. Empty comment `<!>` better not be used for safety. *
According to RFC1866(J), an empty comment "<!>" is a correct comment as no pair of "--" comment. Yet you better not write it to avoid confusion. In XML(J), such an expression does not exist.
28. Comment such as `<!->` is incorrect. *6*
The followings are not correct as comment.
<!->
<!-->
<!--->
29. Do not write comment in <TITLE> *3*
<TITLE> should not contain anything else than text including comment. Please see HTML4.01(J).
30. Writing `<` or `>` in comment may confuse some WWW browsers.*
Enclosing a part of HTML like this
<!-- <A href="～">TEXT</A> -->
is a popular way to comment out. But some of the WWW browsers consider
<!-- <A href="～">
as comment. This is not a fault of the browsers and it is just a specification of old browsers. However, it has been changed in recent browsers. This does not deduct any point.
31. Comments can not be nested. *6*
You are not allowed to nest comments.
<!-- <!-- TEXT --> -->
This nested comment is handled as
<!-- <!-- TEXT -->
in most of the browsers. In SGML, the "TEXT" part is considered as non-comment.
32. Do not put a blank between `--` and `>` in close comment. *
"<!-- ～ -- >" is allowed according to the spec. (not in XML(J)) However, "<! -- ～ -->" is forbidden. In this case, you will be alerted that there is a blank between < and a tag element name
33. Use `-->` as close comment instead of `--!>`. *6*
Some WWW browsers close a comment at "--!>" as intended, but in other browsers the rest of the document are all igonored.
Some people simply misunderstand comment as "<!- ～ ->"
34. Comment in the NNth line is not closed. *6*
This error is alerted when "<!--" is present without "-->".
35. <TAG in the NNth line is not closed. *6*
This error is alerted when a tag starts with "<" and ">" is missing.
36. Do not include a blank between `<` and `TAG`. *6*
Any tag must start with "<TAG". If a blank is included like "< TAG", it will not be handled as a tag. When you want to write "<" as a character "<", it has to be "<". Please see Entity Reference for details.
Although patent application HTML allows this, Another HTML-lint 5 still alert you for this error.
37. Unexpected `<` is present in <TAG>. There might be an unclosed tag. *6*
This often happens when a correct tag is written right after an unclosed tag.
<A href="～"><IMG src="～" </A>
In the above example, ">" will be added in front of </A>.
Technically, this is not wrong in terms of SGML as according to SGML declaration the > is allowed to be omitted when SHORTTAG YES is defined. Every HTML defines SHORTTAG YES. Some of the end tags can be written as </> when it is clear which start tag the end tag corresponds to. However WWW browsers do not understand such strict SGML rules. Please see HTML4.01(J) for details.
38. Empty element tag <TAG> has to be closed as <TAG />. *5*
In XHTML1(J), empty element tags such as <br> and <hr> have to be <br /> and <hr />.
Technically, <br></br> are OK to write. Please refer to Missing end tag as well.
39. Put a space before `/>` when closing empty element tag <TAG> *3*
XHTML1(J) recommends to put a space before /> like <br /> and <hr /> when closing empty element tags. This is due to user agents which do not understand XML. (Appendix C.2)
The reason why this is recommended for such user agents is as below.。
/ can not be an element name, but old user agents consider br/ as element name and an unkown tag, so it will be just ignored. In case it is written as <br />, however, it will be considered as a known tag and will work as line break.
In XML(J), the space is not necessarily required. This error is not alerted when application/xhtml+xml is selected as media type.
40. Do not include even a blank as an element of empty element tag <TAG>. *6*
According to XML Content of Elements(J), an empty element tag can not include anything between start tag and end tag like <tag></tag>. That is, even a blank can not be included.
41. Empty element tag should be written as <TAG /> *3*
XHTML Guideline C.3(J) says that an empty element tag should be written as <tag /> instead of <tag></tag> for backward compatibility.
This error is not alerted when application/xhtml+xml is selected for media type.
42. Do not close non-empty element tag <TAG> with `/>` . *5*
XHTML1(J) says you are not allowed to write non-empty tags such as <p> as <p />. It has to be <p></p>. (Appendix C.3)
This error is not alerted when application/xhtml+xml is selected for media type.
43. Do not write <TAGA> inside <TAGB>～</TAGB> at the NNth line. *6*
Tags often require the pair of start tag <TAG> and end tag </TAG>. It is clearly defined what kind of elements are available for the tag.
HTML4.01 Strict(J) strictly differentiates between block-level elements and in-line elements, therefore you may wonder "why is this an error?" For example, in-line elements can not be written inside <BODY> or <FORM>, so the following example is incorrect according to HTML4.01 Strict as <A> and <INPUT> are in-line elements.
<BODY>;
<A>LINK</A> ← Alert: <A> inside <BODY> ;
<FORM>;
<INPUT>WHY? ← Alert: <INPUT> inside <FORM> ;
</FORM>;
</BODY>
This can be correct as below.
<BODY>;
<P>;
<A>LINK</A>;
</P>;
<FORM>;
<P>;
<INPUT>WHY?;
</P>;
</FORM>;
</BODY>
If you simply declare "HTML4.0" as DOCTYPE without knowing what it means, you will get a lot of errors. In that case, you better choose HTML4.01 Transitional declaration and should learn more about DOCTYPE.
Besides HTML4.0, a famouse indiscernible mistake is
<A href="～"><H3>TEXT</H3></A>
In HTML3.2 and HTML4.0, you can not write <H3> inside <A>～</A> (although it is available in HTML2.0). It should be written as
<H3><A href="～">TEXT</A></H3>
However, most of the browsers can display both of them as expected.
In addition, this error is often alrted when you forget </A>.
<A href="yama.html">ABCDEFGHIJKLMN
<A href="kawa.html">OPQRSTUVWXYZ
Since </A> can not be omitted, it is considered that <A> is inside <A>～</A>, but <A> can not be present inside <A>～</A>
If you are alerted for this error when <UL> or <OL> is nested, you may wonder "<UL> can not be nested?".
<UL>;
<UL>～</UL>;
</UL>
This is not correct. To nest <UL>, you can write it as below.
<UL>;
<LI><UL>～</UL></LI>;
</UL>
The end </LI> can be omitted.
When you forget <TR> in <TABLE>, you may be alerted that <TD> can not be written in <TBODY>. This often happens in HTML4.01.
<TABLE>;
<TD>～</TD>;
</TABLE>
Therefore, please do not think like "What is <TBODY>!?" You probably just forgot <TR>.
Another mistake is writing <NOFRAMES> right under <HTML>. Even many of reference books say that is correct, but it is wrong. It has to be inside <FRAMESET>～</FRAMESET>. Furthermore, <NOFRAMES> is written as <NOFRAME> in those reference books. <NOFRAME> tag does not exist. Although www browsers understand <NOFRAME>, you still better write correct tags.
In Laura Lemay's HTML reference book, there is an example which <IMG> is included inside <PRE>～</PRE>, but that is forbidden in current HTML including HTML1.0. However it is possible in HTML+
In HTML4.01(J), <INS> and <DEL> allow different elements depending on in which elements they are used. That is, when they are used as in-line elements, block-level elements can not be written.
<P>;
<INS><DIV>…Block Level Element…</DIV></INS>;
</P>
This example is incorrect. <P> can not contain <DIV>.
44. You better not write <TAGA> inside <TAGB>～</TAGB> at the NNth line. *3*
It is still OK to write, but not recommended. It may be forbidden in the future. This error does not deduct any point.
45. Do not write <TAGA> outside <TAGB>～</TAGB>. *3*
Some tags can be written only in particular tag elements. You are typically alerted for included elements, but this error occurs when it can not be defined by DTD.
<IMG ISMAP> can not be present outside <A HREF>～</A>. This is ruled by HTML2.0 and ISO/IEC 1544 etc.
46. <TAGA> is available only once in <TAGB>～</TAGB>. It appears in the NNth line again. *6*
Some tags such as <BODY>, <TITLE> and <CAPTION> etc. are not allowed to appear more than once. It does not mean that you can not write these tags more than once in HTML. It means for example you can write only one <BODY> in <HTML>～</HTML>. Of course <HTML> can appear only once, so <BODY> is also available only once. However, <CAPTION> can appear once in every <TABLE>～</TABLE> and <TABLE> can appear multiple times, therefore <CAPTION> may appear more than once in a HTML.
47. <TAGA> and <TAGB> in the NNth line are not allowed to coexist in <TAGC>～</TAGC>. *6*
For example, in HTML4.01(J), <BODY> and <FRAMESET> are both used in <HTML>～</HTML>, but you can not write them together in a same HTML. This will alert you for such restricted tags.
48. <TAGA> has to come right after </TAGB>. *6*
Some tags are order-defined. Inside <HTML>～</HTML>, <BODY> has to come after <HEAD>. Inside <TABLE>～</TABLE>, <CAPTION> always has to come before <TR>.
49. <DD> has to come right after </DT>. *3*
In <DL> element, you can write <DT> tag and <DD> tag, but according to RFC1866(J), it is not recommended to write multiple <DD>s for a single <DT>.
<DL>;
<DT>HEADING1;
<DD>～;
<DT>HEADING2;
<DD>～
The above example is of course correct, but the following one is incorrect.
<DL>;
<DT>HEADING1;
<DD>～;
<DD>～
The following example is available on the other hand.
<DL>;
<DT>HEADING1;
<DT>HEADING2;
<DD>～
When you want to repeat <DD>, you can use <BR> instead.
Regarding this, DTD of HTML+ defines that DD can not be repeated sequentially.
<!ELEMENT DL - - (DT+,DD)+>
RFC1866(J) defines as below. The order is not regulated.
<!ELEMENT DL - - (DT|DD)+>
Since HTML+ was enacted in 1993/11 and RFC1866 was enacted in 1995/11, the RFC1866 definition is probably inherited from HTML+ or was just left by mistake.
In HTML4.01(J), there is an example which repeats <DD> sequentially. That means it is allowed in HTML4.0. You will not be alerted for this <DD> error in HTML4.0 or newer.
50. <TAGB> is always required in <TAGA>～</TAGA>. *6*
Some elements are essential. For example, <HEAD>～</HEAD> always has to contain <TITLE>.
51. Nothing is contained between <TAG> and </TAG>. *
Some tags do not prefer empty elements. E.g.:
<ADDRESS></ADDRESS>
In this example, what is the <ADDRESS> for? Typically, when <P> is used as an alternative to <BR>, </P> is considered omitted and you will be alerted. <P> is for paragraph, not for line break.
In addition, the following example
<A name="anchor"></A>
does not work in some brpwsers such as Lynx. However, this is not grammatically wrong. Anchor tag is supposed to be used for a specific point not for a range. It seems to be a problem of Lynx. In the recent Lynx(2.8.1), however, it has been fixed.
52. Nothing is contained but a blank character between <TAG> and </TAG>. *3*
A double-byte space □ is often used to adjust the layout, for example <P>□</P>. This might work for the layout, but is not recommended. However, the double-byte space may be purposely used for some proper reason. Another HTML-lint 5 considers a single space ( ,   and ) as a blank character as well as a double-byte space.
Accessibility Guidelines says that stylesheet should be used for visual effect instead of a blank <TD> etc. This error does not deduct any point.
53. <TAG>～</TAG> contains only a space and <BR>. *
Some people change <P> to <BR> as it was detected as an error, and then change it to <P><BR></P> as <BR> can not be written in <BODY>～</BODY>.
This kind of thing may happen when people just try to get full marks, but some people might write <P><BR></P> on purpose.
This error is alerted only for <P> <TD> <TH>. This does not deduct any point.
54. <TAG> is unknown tag. *5*
The specified tag is simply invalid. It is possibly a wrong spelling. <NOFRAMES> is often described as <NOFRAME> in reference books. <CENTER>～</CENTER> tag does exist, but <LEFT>～</LEFT> does not.
Please see the tags list as well.
55. <TAG> is for XXXX. *5*
The tag is not supported by the HTML version you are currently validating, but is supported by other version(s). If you are alerted for this error many times, your DOCTYPE declaration might be unsuitable. Please see the tags list as well.
56. <TAG> is not recommended. *3*
The tag is a deprecated tag and you should not use it. The followings are the alternative tags.
<CENTER> | → | <DIV align="center"> |
<DIR> | → | <UL> |
<MENU> | → | <UL> |
<ISINDEX> | → | <INPUT> |
<XMP> | → | <PRE> |
<APPLET> | → | <OBJECT> |
However, you will be alerted for different tags depending on the HTML version and careful attention is required for replacing element names.
57. <TAG> is not recommended. Use stylesheet instead. *3*
In HTML4.01, <FONT> and <U> etc. are defined as a deprecated tag. It says as these tags are not provided to specify document structure, stylesheet (CSS1(J)/CSS2(J)) should be used instead. In spite of that, <B> and <I> are not excluded.This does not deduct any point.
58. Another HTML-lint 5 can not evaluate <TAG> correctly.
<XML> supported by MSIE5.0 and custom Element declared by <HTML xmlns:namespace> can not be understood.
<XML> is used to insert XML into HTML, but Another HTML-lint 5 does not understand XML namespace etc. Regarding tags in <XML>～</XML>, Another HTML-lint 5 does not check anything except the correspondence relationship between start and end tags. This does not deduct any point.
59. <TAG> should not be used. *3*
WAI strongly insists that some tags such as <BLINK> and <MARQUEE> should be avoided.
60. <TAG> is required here. *6*
A required start tag is omitted. <HTML> is always required in ISO/IEC 15445. In XHTML1(J), every start tag is required.
61. <TAG> is omitted here. Try not to omit it. **
Some of start tags are allowed to be omitted in terms of specs. For example, <HTML>, <HEAD> and <BODY> can be omitted. However, you better not omit such tags.
When trying to validate plain text containing no tag as HTML, Another HTML-lint 5 adds omittable tags as below. However, <TITLE> will not be added as it is not an omittable tag. Thus, the following HTML is not a correct HTML as <HEAD> does not contain <TITLE> which is required.
<HTML>;
<HEAD>;
</HEAD>;
<BODY>;
TEXT;
</BODY>;
</HTML>
Please.
62. <TAG> is omitted here. **
Some of the start tags extended in HTML4.0 are omittable. For example, in HTML3.2(J), TABLE is like this:
<TABLE>;
<TR><TD>TEXT</TD></TR>;
</TABLE>
In HTML4.01, it is considered as:
<TABLE>;
<TBODY>;
<TR><TD>TEXT</TD></TR>;
</TBODY>;
</TABLE>
<TBODY> and </TBODY> are omittable. This does not deduct any point.
63. </TAG> is required here. *6*
A required end tag is missing. In XHTML1(J), none of the end tags is omittable.
64. </TAG> is considered omitted. **
There are many omittable tags. In HTML3.2(J), the following end tags are defined as omittable. This varies depending on the HTML.
| </HTML> | |
| </HEAD> | |
| </BODY> | |
| </PLAINTEXT> | |
| </P> | |
| o | </DT> |
| o | </DD> |
| o | </LI> |
| </TR> | |
| o | </TH> |
| o | </TD> |
| o | </OPTION> |
You will be alerted when these tags are omitted except the o attached tags, which are typically omitted in most cases. It does not mean these tags should be omitted, it just means you still better write them although they can be omitted.
</TR> is excluded. Most of the examples given in HTML4.01(J) are omitted. This is because some browsers including Mozilla can not handle nested tables etc. when </TR> is omitted. In addition, if Mozilla is selected for validation, </TH> and </TD> are also excluded.
It is not true that </P> is omittable for backward compatibility. There is no backward (HTML1.0) compatibility.
For example, <DL>～</DL> can contain only <DT> and <DD>, so even in the following case,
<DL>;
<DT>ABCDEFG
</DT> is still considered written right before <DT>, <DD> or </DL>. On the other hand,
<P>HIJKLMNOP
in this case, it is hard to assume where </P> is meant to be written as <P> can appear almost everywhere.
<P>Some famous doctor says;
<BLOCKQUOTE>Hero A and Hero B is the same person because..</BLOCKQUOTE>;
I was so surprised when read this.</P>
This example is apparently a wrong use of <BLOCKQUOTE> writing inside <P>. It should be as below.
<P>Some famous doctor says </P>;
<BLOCKQUOTE>Hero A and Hero B is the same person because..</BLOCKQUOTE>;
<P>I was so surprised when read this.</P>
Also, some people use <P> as line break, but <P> indicates paragraph and should not be used as line break.
That is ....<P>;
<TABLE>～
In this case, </P> is considered omitted as <TABLE> can not contain <P> and you will be alerted. It should be corrected like this:
<P>That is....</P>;
<TABLE>～
<P>～</P> frequently contains unavailable tags which are not supposed to be contained.
<P align="center"><HR></P>
Some HTML editors output such ridiculous codes as above. <HR> should be written outside <P> and if <P>～</P> gets empty, you should delete the <P>～</P>.
Below is my personal opinion.
<P> is paragraph. Often you may want to include some other blocks such as quotation in a paragraph. For example,
You can pick
1. ABCD
2. EFGH
3. IJKL
one of them.
If you try to correct the above example to follow HTML grammar, you have to exclude <OL> from <P> like this:
<P>You can pick </P>
<OL>
<LI>ABCD
<LI>EFGH
<LI>IJKL
</OL>
<P>one of them.</P>
However, it looks obviously wrong. The natual structure probably is like this:
<P>You can pick
<OL>
<LI>ABCD
<LI>EFGH
<LI>IJKL
</OL>
one of them.</P>
But this is not allowed in HTML.
65. </TAG> is considered omitted here. **
This error is displayed when a omittable end tag (such as </LI> or </DT>) is obviously omitted. Please see the above section as well. This error does not deduct any point.
In case of using <P>s as below,
<P>Monday
<P>Tuesday
</P> is considered omitted at the end of "Monday". If another <P> comes after "Tuesday", </P> is also considered omitted at the end of "Tuesday". If not, </P> is not considered as an obviously omitted tag.
According to Laura Lemay's HTML book, </LI> does not exist. However that is only specific to HTML of that time, and </LI> does exist in most of the currect HTMLs. Careful consideration is required to tell what you can believe in such resorces.
Even a reference book written for HTML4.0 says "<LI> does not have a end tag."
66. Do not specify any attribute for end tags </TAG> *6*
It is not allowed to specify any attribute for end tags.
67. <TAG> does not have an end tag </TAG> . *6*
Some tags do not take end tags, for example, <BR> does not have an end tag like </BR>. However, different HTML versions define different rules. <BASEFONT> does not take an end tag in HTML3.2(J), but does take </BASEFONT> as an end tag in Mozilla.
In XHTML1(J), every tag has an end tag. Regarding empty element tags,
<br />
<br></br>
they are both allowed. <br /> is an abbreviation for <br></br>. The following example is incorrect,
<br>ABCDEFG</br>
because it is an empty element and not allowed to contain any element.
68. Do not include a blank character at the beginning and the end inside <TAG>～</TAG> *
This error is detected for, for example the following.
<A href="～">
<IMG src="～">
</A>
In this example, a line break is input right after the start tag and right before the end tag, and the link hotspot will not be displayed correctly in many of the old browsers.
It can be corrected as below.
<A href="～"><IMG src="～"></A>
Regarding a blank character right after the star tag, for example when it is inserted right after <LI>, leading spaces of the list may get collapsed. In HTML4.01(J), however, there are a lot of examples giving priority to a blank character.
Introduction to HTML3.2(J) says that a line break right after the start tag and right before the end tag is ignored, although most of the existing browsers do not follow that.
HTML4.01(J) says that such a blank character right after the start tag and right before the end tag is not supposed to be displayed. If so,
<P>We offer free<A href="～"> technical support </A>for subscribers.</P>
this example will be displayed with no space between "free" and "technical" as well as "support" and "for". It can be corrected like this,
<P>We offer free <A href="～">technical support</A> for subscribers.</P>
This error does not deduct any point for now.
69. Orphan </TAG>. Start tag <TAG> is missing. *6*
Most of the start tags are not allowed to be omitted. An end tag can not exist by itself. You may have simply forgotten to delete the end tag, or it might be due to Incorrectly nested tags.
70. <TAGA> is illegally nested in <TAGB> at the NNth line. *6*
Below is one of the examples for this error.
<P>AAAAAAA<BIG>BBBBBBB</P>CCCCCCC</BIG>
This example is easy to correct, but it could be very complicating if the tags are deeply nested.
71. <TAG> is nested too deeply. *6*
SGML declaration(J) QUANTITY TAGLVL restricts nesting to 100 levels.
This warning only indicates the error was detected at the <TAG>.
72. End tag </TAG> required for <TAG> is missing at the NNth line. *6*
This error alerts you that a required end tag is missing. Especially </A> is often missing. Some browsers complement </A> automatically, but that does not always work as intended. Also, in this </A> missing case, you may be alerted when <A> is written inside another <A>.
Please see Omittable end tags as well.
73. Do not write plain text in <TAG>～</TAG>. *6*
<HEAD> and <UL> etc. allows only certain tags for their elements. That is, you can not write it like below:
<UL>ABCDEFG</UL>
It should be:
<UL><LI>ABCDEFG</UL>
HTML4.01 Strict even forbids to write plain text directly in <BODY>～</BODY>. That is, you can not write it like below:
<BODY>
ABCDEFG
</BODY>
It should be:
<BODY>
<P>
ABCDEFG
</P>
</BODY>
In this way, <BODY> can take only block-level elements.
74. Invalid characters `XXX` is written in <TAG>. *6*
An element name or attribute name consists of alphameric characters, period "." and hyphen "-". The initial character is alphabetical character. HTML4.01(J) allows underscore "_" as well as colon ":". To include other characters such as a balnk character to an attribute value, you need to enclose them with quotation marks. The popular mistakes are misusing underscore instead of hyphen, inserting a double-byte space between attributes and writing an attribute name in double-byte characters. You will get many errors in such cases.
Please take a look at Unnecessary "<" in tag as well.
75. Do not write empty element tag as `<TAG />` in XXXXXX. *5*
Closing an empty element tag with /> is not allowed except in XHTML.
76. Do not use mixed-case name for element and attribute. *
An element name and attribute name are not case sensitive, thus the followings are handled as a same tag. (except for XHTML)
<BLOCKQUOTE>
<BlockQuote>
<blockquote>
However, it is commonly said that HTML looks better when upper-case and lower-case is unified. Element name and attribute name are checked separately. In a HTML4.01(J) reference, element names are written in upper-case and attribute names are written in lower-case. It says that is easier to read.
This error is only a remnant from Weblint, and does not deduct any point.
Please remember XML(J) does distinguish upper from lower case as to element name and attribute name. Regarding XHTML1(J), all element names and attribute names have to be lower-case.
79. Unknown attribute `ATTR` is specified for <TAG>. *5*
Invalid attribute is specified. It may be a spelling mistake. However, reference books could give a wrong explanation. Actually, some Mozilla reference book says that NAME attribute is used to name <LAYER> , but that is not true. Correctly, it is ID attribute instead of NAME attribute, you can confirm it on Netscape website.
80. <TAG> attribute `ATTR` is specific to XXXX. *5*
The attribute is not supported in the selected HTML, but is supported in other version(s) of HTML. If you get this error a lot, your DOCTYPE declaration might be improper.
81. <TAG> attribute `ATTR` is not recommended. *3*
The attribute is a deprecated attribute and will not be supported in the future. You better avoid using such tags. None of stylesheet properties are alternative to these attributes. Especially, TARGET attribute of <A> is not recommended at all. You should avoid using FRAME and giving forced direction.
XHTML1.0(J) does not recommend the use of NAME attribute for <A>. Use ID attribute instead. In XHTML1.1, that kind of NAME attribute is already obsolete.
82. Use stylesheet instead of <TAG> attribute `ATTR`. *3*
The attribute is one of the attributes which stylesheet(CSS1(J)/CSS2(J)) is recommended to use instead of. Unfortunately, however, some of these attributes are not replaceable with stylesheet properties (not sure about CSS2), and some of the browsers have not supported stylesheet yet. Thus, you may have no choice but to use these attributes in some cases. This error does not deduct any point.
83. Another HTML-lint 5 is unable to evaluate <TAG> attribute `ATTR`.
Another HTML-lint 5 do not understand <HTML xmlns:namespace> supported by MSIE5.0 so well.
This error does not deduct any point.
84. Missing required space before <TAG> ATTR. *6* or **
In the example below,
<BODY bgcolor="#FF00FF"link="#808080">
there is no space between #FF00FF and link.
This is not considered an error in HTML, but is a grammar violation in XHTML.
85. Same attribute is repeated for <TAG> *5*
You can not repeat the same attribute for a tag.
<BODY bgcolor="#FF00FF" bgcolor="#808080">
This is not allowed.
86. ATTR attribute is required for <TAG>. *6*
Some tags have required attributes. For instance, in HTML3.2(J), <BASE> always requires HREF attribute. Also, <AREA> requires ALT attibute. <IMG> does not necessarily require ALT attribute as to HTML3.2, but does require it in HTML4.01. Please see ALT attribute for as well.
87. ATTRA and ATTRB must be a pair for <TAG> *3*
NTT DoCoMo imode has some pair attributes which must be specified together.
<A IJAM HREF><A TELBOOK KANA EMAIL HREF>
88. ATTRA and ATTRB can not be specified together for <TAG>. *3*
NTT DoCoMo imode 4.0 has some attributes which are not allowed to coexist.
<A IJAM><A ISTA>
89. <TAG> ATTR attribute requires an attribute value. *5*
Most of the attributes are specified with attribute values.
<BR clear>
This is incomplete.
<BR clear="all">
Specify the attribute value as above.
<BR clear=>
This will be detected as another error.
90. An attribute value is missing for <TAG> ATTR attribute *6*
No attribute value is specified after "=",
<A name=>
as above.
91. <TAG> ATTR attribute value across multiple lines. *
This is simply a false positive warning. Attribute values are allowed to across multiple lines and line breaks are handled as spaces.
<AREA shape="rect" coords="10, 12, 50, 76">
This does not deduct any point.
92. A space is included before and after attribute value delimiter = for <TAG> ATTR. *
This is allowed in RFC1866(J), but some HTML checker detect this as an error. This does not deduct any point.
93. Unclosed quotes for <TAG> ATTR attribute value *3*
When ">" is included as a part of attribute value inside quotes, the ">" may be considered as a tag closer.
<IMG src="～" alt="a>b">
This shoud be corrected as below.
<IMG src="～" alt="a>b">
Use entity reference like this. According to RFC1866(J), it is not completely wrong. But it is hard to tell if it is a part of attribute value or a closing quotes is missing, so Another HTML-lint 5 consider this a grammatical error.
94. Lorem Ipsum is simply dummy text of the printing and typesetting
You can use both double quotes "～" and single quote mark '～' to enclose attribute values. Most people use '～' when you want to express double quotes itself.
"We say "So!""
'We say "So!"'
They are both same. But some browsers do not understand single quote mark (e.g. MSIE for MacOS). This error does not deduct any point.
95. Enclose <TAG> ATTR attribute value `XXXX` in quotes. *6*
Not all attribute values are necessarily enclosed in quotes (except XHTML). For instance, when a value is less than 72 characters and consists of alphameric characters, period "." and hyphen "-". Only when the avlue is not applicable to that, you have to enclose it in quotes. That is, you have to use quotes for +5 but not for -5. Please ensure that underscore "_" is not included, especially if you are a C language programmer.
<A href="～" target=_top>
This should be:
<A href="～" target="_top">
Although for HTML4.01(J), you do not have to enclose _top in quotes, it is still better for other HTML versions.
In Laura Lemay's reference, there are examples with <FONT SIZE=+5> and <HR WIDTH=90%> etc., but those are incorrect.
XHTML1(J) requires every attribute to be enclosed in quotes.
96. Better to enclose <TAG> ATTR attribute value `XXXX` in quotes. **
You will be alerted if a attribute value containing underscore "_" or colon ":" is not enclosed in quotes in HTML4.01(J). It is better to enclose it in quotes for other HTML versions.
97. <TAG> ATTR attribute value `XXXX` is not enclosed in quotes. *
This caution is for a naked (not enclosed) attribute which is not necessarily to be enclosed in quotes. You can activate this check only if you want all the attribute values to be enclosed. This is not mandatory and does not deduct any point.
As for XHTML1(J), this error is not detected as quotes are not omittable.
98. A blank character is included before/after <TAG> ATTR attribute `XXXX`. *
This warning is output when a blank character is included before or after a value of the attribute which takes particular values.
<P align=" center">
<UL type="disk ">
<LI value=" 5 ">
I am not so sure if these are officially wrong, but according to 6. Element structure in this website about SGML, it seems these are incorrect.
As for XHTML1(J), such blank characters are simply ignored and other sequential blank characters are considered a single blank character. That is, all of the above examples are allowable.
99. <TAG> ATTR attribute value `XXXX` is not recommended. *3*
The value is a deprecated value. You should avoid using such a value.
100. <TAG> ATTR attribute value can not be empty. *5*
You can not specify an empty value for the attribute which takes particular values. E.g.:
<P align="">
<UL type="">
<LI value="">
These are all incorrect. Some attributes allow empty values, such as <IMG alt="">.
In case of specifying empty URI like <IMG src="">, another warning is output.
101. <TAG> ATTR attribute value exceeds NN characters. *5*
In HTML, the length of an attribute value is limited to 1024 characters. This is defined in SGML宣言(J) QUANTITY LITLEN. As for HTML4.01, it is limited to 65536 characters.
NTT DoCoMo imode has their own limitation.
<OPTION VALUE>: less than 10 characters (42 for 2.0, no limit for 3.0)<A CTI>: less than 128 characters<A SUBJECT>: less than 30 characters<A BODY>: less than 500 characters<A TELBOOK>: less than 20 characters<A KANA>: less than 18 characters<A EMAIL>: less than 50 characters
1 character = single-byte, double-byte characters = 2 characters
102. <TAG> ATTR attribute value `XXXX` is incorrect. *5*
There are many attributes which take only particular values. For instance, <DIV ALIGN> takes any of LEFT, CENTER, RIGHT and <BR CLEAR> takes any of ALL, LEFT, RIGHT, NONE.
- <BASEFONT SIZE> takes any of 1 to 7 but <FONT SIZE> can take "-3" or "+1" etc.
- Some of WIDTH attributes take "50%" or "3*" etc. besides numeric numbers. Do not use something like "180pt" as it is specific to stylesheet.
- ACCESSKEY attribute takes only one character of ASCII.
- TABINDEX attribute value specified in form control etc. is limited to the range of 0 to 32767 in HTML4.01(J).
- ID attribute has to start with alphabetical character and to consist of alphameric characters, hyphen or period. In HTML4.01(J), underscore and colon are also added to the options. Please see Warning about lower case ID as well.
In XHTML, it has to start with alphabetical character or underscore and to consist of alphameric characters, hyphen, period or underscore. Please note that colon in not included. Also, in XHTML, you can use other characters than ASCII as ID, but Another HTML-lint 5 does not consider them. Any other characters than ASCII gets an error. In addition, it is not allowed to start with "xml" regardless of the case. (XML1.0 2.3 Common Syntactic Constructs)。 - LANG attribute value has to follow ISO0639.
103. <TAG> ATTR attribute value `XXXX` is not correct. It has to be a #RRGGBB form or a set color name. *5*
BGCOLOR etc. has to be specified in a particular form such as "#00FF80", or in a set color name. In HTML3.2(J) or HTML4.01(J), there are 16 color names and they are extended to 140 color names in Mozilla and MSIE.
104. <HEAD> PROFILE attribute value is a single URI according to DTD. **
HEAD PROFILE attributes are all defined as a single URI in HTML4 - XHTML1.1 according to DTD.
<!ATTLIST HEAD
%i18n;
-- lang, dir --
profile %URI; #IMPLIED -- named dictionary of meta info --
>
However, HTML4.01(J) says as below and they are conflicted.
- 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 validates PROFILE attributes as a multiple URIs string separated by a space.
105. Better not use <TAG> ATTR attribute value `XXXX` *3*
XHTML ID attribute value is different from HTML one. They do not have compatibility. The ID value starting with an underscore "_" can be used only for XHTML but not for HTML. Thus, you better not use such an ID attribute value.
106. <TAG> ATTR attribute value `XXXX` has to be `xxxx`. *5*
In XHTML, attribute values are case sensitive.
107. <TAG> ATTR attribute value has to be `XXXX`. *5*
Some of the attributes have their own particular values (#FIXED in DTD) Any other attribute values than the fixed values are not allowed for those attributes.
108. <TAG> ATTR attribute name and attribute value are the same. Omit a attribtue name. **
For instance,
<DL compact>
this is omitted style of
<DL compact=compact>
The "compact=" part is omitted (not a value). Some browsers do not understand these unabbreviated way. It is better to abbreviate.
In XHTML1(J), on the other hand, attribute names are not allowed to omit.
109. <TAG> `ATTR` attribute name is not omittable. *5*
In XHTML1(J), attribute name is always required. For instance,
<dl compact>
has to be
<dl compact="compact">
110. Attribute name ATTR is omitted from <TAG> `XXXX`, but it may not work. **
Omission of attribute name is allowed in other canses besides compact=compact
<P center>
like this (except XHTML1). This is an omitted way of
<P align="center">
It is because no other attribute takes a value "center". However, not many browsers are able to understand this far.
Please note that <TABLE border> is considered as <TABLE frame=border> in HTML4.01.
111. Entity reference `&xx` requires `;` at the end of it. *3*
Entity reference is one of forms of writing, for example, < and &. This is used to write "<" and ">" etc. in text. Entity reference starts with "&" and ends with ";". According to SGML, the end semi-colon is omittable when it is trivial such as
abc < xyz
According to HTML4.01(J), however, those omission are not recommended.
112. Entity reference `'` should be `'`. *3*
XHTML 1.0 (Second Edition) C.16 says it is better to use ' instead of ' for backward compatibility.
113. Hexadecimal character reference in XHTML has to start in a lower case like `ሴ` . *3*
XHTML is case sensitive and hexadecimal character reference also has to start in a lower case &#x. ሴ is wrong.
114. `&xx;` is unknown entity reference. *3*
Names to be refered by entity reference ("<" and ">" etc.) depend on HTML. They are case sensitive, thus "&" and "&" are considered different things. Some of the browsers do consider them as the same thing, but that is originally incorrect. If you write as below
abc<xyz
"<xyz" is then considered as entity reference.
Regarding CGI calling, & is historically used for parameter calling. The & also has to be &.
<A href="uso.cgi?foo=1&bar=2">
is not correct.
<A href="uso.cgi?foo=1&bar=2">
is correct.
<A href="uso.cgi?lt=1>=2">
will be considered as
<A href="uso.cgi?lt=1>=2">
.
That you have to use entity reference even for CGI calling is written in RFC1866(J) 8.2.1 and HTML4.01(J) etc. Sometimes it is said that parameter separator should be ";" instead of "&". Yet still both of them can be used at least in recent versions of nonstandard Perl library cgi-lib.pl or standard CGI.pm.
115. Character reference `&#NNN;` exceeds the limit. The limit is to `&#MMM;`. *6*
Every HTML has a different limit of character code. For example, 255 for HTML2.0 and HTML3.2 and 1114111 for HTML4.0. That is stated in SGML declaration. You will be alerted if the specified value exceeds the limit. Mozilla and MSIE do not check this as DTD does not exist for them.
116. Do not use character reference `&#NNN;` *6*
You can not use character reference such as & for J-SkyWeb HTML.
117. Meta-character `X` has to be written as `&xx;`. **
You are not allowed to write "<" or "&" directly in text except some elements such as for <SCRIPT>. You have to write them using entity reference "<" and "&". You also have to use entity reference in <PRE>.
Technically, when you write as below
abc & lt xyz
the "&" is obviously not a entity reference, so it is displayed as "&" as intended. However it is still better to use entity reference.
118. `"` in text should be `"`. *
This prompt you to use entity reference for " in text for safety. However that is not practically necessary. This warning does not deduct any point.
119. LANG attribute should be specified for <HTML>. *3*
According to WAI, it is recommended to use LANG attribute to define the language of the document for <HTML>. In case of Japanese, it will be like this:
<HTML lang="ja">
<HTML lang="ja-JP">
In case language code is specified by Content-Language in HTTP response header, you will not be alerted.
XHTML requires xml:lang attribute and XHTML1.0 requires both.
Please seeISO0639 for LanguageCode.
120. xml:lang attribute is also required when lang attribute is specified for <tag>. *3*
XHTML1.0(J) C.7 prompts specifying both lang attribute and xml:lang attribute.
121. Mismatch between the values of lang attribute and xml:lang attribute specified for <tag>. *3*
In XHTML, when lang attribtue and xml:lang attribute are both specified, the values have to be the same.
122. LANG attribute is specified as `xx` in the NNth line, but <TAG> ATTR attribute value seems like Japanese. **
WAI prompts you to define the change of languages using LANG attribute. You will be alerted if Japanese characters are used as an attribute value when something else other than LANG="ja" and LANG="ja-JP" is specified. For instance,
<P lang="fr">
<IMG src="france.png" alt="フランスの地図">
</P>
Also, specified attribute is enabled from the tag regardless of the order (as described here), so
<INPUT lang="de" value="ドイツ人専用">
<INPUT value="ドイツ人専用" lang="de">
are both to be warned.
You will be alerted only when CHARSET is specified as Japanese (JIS, EUC, Shift JIS) or when the document is considered written in Japanese with no CHARSET specified. This warning does not deduct any point.
Originally specified language has nothing to do with character code, but Another HTML-lint 5 is based on character code as it is aimed at Japanese HTML.
XHTML uses xml:lang attribute instead.
123. LANG attribute is specified as `xx` in the NNth line, but Japanese character seems to be included in text. **
WAI prompts you to define the change of languages using LANG attribute. You will be alerted if Japanese characters are included in text when something else other than LANG="ja" and LANG="ja-JP" is specified. (except <SCRIPT>～</SCRIPT> etc.)
<P lang="es">
お元気ですか。今、スペインに来ています。
</P>
is incorrect.
You will be alerted only when CHARSET is specified as Japanese (JIS, EUC, Shift JIS) or when the document is considered written in Japanese with no CHARSET specified. This warning does not deduct any point.
Originally specified language has nothing to do with character code, but Another HTML-lint 5 is based on character code as it is aimed at Japanese HTML.
XHTML uses xml:lang attribute instead.
124. <LINK REV="MADE" HREF="mailto:～"> is not included in <HEAD>～</HEAD>. *
Some of browseres such as Lynx use this information to send an email etc. This tag is also useful for defining the author of the HTML.
However, old Mozilla does not support <LINK> tag, thus Another HTML-lint 5 outputs an error even when this tag is written. Please just ignore it. Mozilla4.0 finally supports <LINK>.
This warning does not deduct any point.
125. Navigation link such as <LINK REL="NEXT" HREF="～"> is not included in <HEAD>～</HEAD>. *3*
<LINK> tag enables you to describe the relation between HTML documents.
<LINK rel="INDEX" href="./index.html">
<LINK rel="NEXT" href="chapter3.html">
<LINK rel="PREV" href="chapter1.html">
This checkpoint checks the following link types for navigation. You will be alerted when none of them is specified.
| START | Start page | |
| NEXT | Next page | |
| PREV | Previous page | |
| CONTENTS | Table of Contents page | |
| INDEX | Index page | |
| GLOSSARY | Glossary page | |
| CHAPTER | Chapter | |
| SECTION | Section | |
| SUBSECTION | Sub section | |
| APPENDIX | Appendix page | |
| HELP | Help page |
Some browsers including Lynx and Mosaic can understand it. This warning does not deduct any point.
126. <LINK> REL attribute value `CONTENT` seems a spelling mistake for `CONTENTS`. **
For navigation, it has to be "CONTENTS".
127. <META NAME="ROBOTS"> CONTENT attribute value `XXXX` is not recommended. *
HTML4.0 makes mention of bot. CONTENT attribute only takes any of the followings as its value. "ALL"、 "NONE"、 "INDEX"、 "NOINDEX"、 "FOLLOW"、 "NOFOLLOW" . They are case sensitive as well (see here for details about the case). Please also seeHTML Author's Guide to the Robots META tag. However, the resource includes some description which is paradoxical.
Please note these descriptions regarding the case have been all deleted since HTML4.01(J). This does not deduct any point.
128. <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="～"> is not included in <HEAD>～</HEAD>. **
Currently most of the HTMLs written in Japanese use JIS, Shift JIS or EUC as a character code. UTF-8 is also available. The following tags should be used to indicate which code the HTML uses.
<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">
When one of these is written, good browsers will display your document in Japanese even if character encoding is set to western. When charset is specified in <META>, the corresponding font will be displayed.
According to RFC1866(J), the <META> information is basically provided for HTTP servers to generate the correct HTTP response header. That is, it is not for browsers. However, most of the current HTTP servers do not execute such complicated processings.
In HTTP1.1 (RFC2068), you have to include CHARSET parameter in HTTP response header. In this case, it means nothing to specify charset in <META> in HTML. In XML(J), CHARSET parameter is required and charset specified in the document is ignored.
Some of the servers use Content Negotiation by filename extension.
hello.html.ja(Japanese HTML)hello.html.en(English HTML)
In the above example, either of them is output as a response for hello.html depending on the language setting of the browser.
FYI: Please note that an URI does not point to any specific resource. A single resource can be pointed by multiple URIs.
This checkpoint is not checked if HTTP response header includes CHARSET parameter. Also, when media type is set to application/xhtml+xml, you will not be alerted for this.
129. The charset `XXXX` specified in <META> is not registered as IANA. **
The various codes used on the internet are managed by Internet Assigned Numbers Authority (IANA). They also manage Character Sets which are specified here.
"charset=x-sjis" and "charset=x-euc-jp" etc. are not registered as IANA. However, some of the old browsers understand these ones, while they do not understand other ones registered as IANA.
Points will not be deducted for charsets starting with x- such as x-sjis and x-euc-jp.
130. Better specify CHARSET for <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="～">. **
You do not necessarily have to specify CHARSET, but according to RFC1945 and RFC2068, ISO-8859-1 is applied when no CHARSET is specified. Therefore, you should specify it when you write Japanese.
You will not be alerted for this when media type is set to application/xhtml+xml.
131. Non-ASCII characters are included before CHARSET specified in <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="～"> *5*
There are more details in RFC2070(J) and HTML4.01(J), but Another HTML-lint 5 only checks if no other characters than ASCII are present before CHARSET is specified. When <TITLE> is written in Japanese, it has to come after <META>.
This checkpoint checks only inside <HEAD>～</HEAD>. You will not be alerted if HTTP response header contains CHARSET parameter and if media type is set to application/xhtml+xml.
132. Non-ASCII characters are included. *5*
This alerts you if non-ASCII code is included when CHARSET code is set to 7bit code such as US-ASCII and ISO-2022-JP.
This checkpoint is not enabled when HTML is specified by DATA area instead of URL.
133. Control character `^X` is included. **
This alerts you if control characters (0x00～0x1F) are included except line breaks, tabs or JIS escape sequence etc.
This checkpoint is not enabled when HTML is specified by DATA area instead of URL.
134. One-byte katakana is included. **
This alerts you if one-byte katakana (katakana part of JIS X 0201) is included when CHARSET is set to Shift JIS. When JIS is specified, you will be alerted if ^[(I escape sequence is included. ^[(I escape sequence is not defined in ISO-2022-JP, so it is wrong to use the escape sequence when ISO-2022-JP is declared.
The reason why one-byte katakana should not be used is mentioned in RFC1468, danger of one-byte katakana and why one-byte katakana is abvoided.
This checkpoint is not enabled when HTML is specified by DATA area instead of URL.
NTT DoCoMo imode and Patent application HTML allow one-byte katakana. In this case, points will not be deducted.
135. Machine-dependent two-byte character `XXXX` is included. **
This alers you if two-byte characters which are not defined in JIS X 0208:1997 are included when the document is written in Japanese.
The following input codes are the letter forms defined in 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) | Digit |
| 3-33 | (2341/8260) | ～ | 3-58 | (235A/8279) | Latin Upper case |
| 3-65 | (2361/8281) | ～ | 3-90 | (237A/829A) | Latin Lower case |
| 4-1 | (2421/829F) | ～ | 4-83 | (2473/82F1) | Hiragana |
| 5-1 | (2521/8340) | ～ | 5-86 | (2576/8396) | Katakana |
| 6-1 | (2621/839F) | ～ | 6-24 | (2638/83B6) | Greece Upper case |
| 6-33 | (2641/83BF) | ～ | 6-56 | (2658/83D6) | Greece Lower case |
| 7-1 | (2721/8440) | ～ | 7-33 | (2741/8460) | Cyrillic Upper case |
| 7-49 | (2751/8470) | ～ | 7-81 | (2771/8491) | Cyrillic Lower case |
| 8-1 | (2821/849F) | ～ | 8-32 | (2840/84BE) | Box-drawing characters |
| 16-1 | (3021/889F) | ～ | 47-51 | (4F53/9872) | Chinese characters of the first level |
| 48-1 | (5021/989F) | ～ | 84-6 | (7426/EAA4) | Chinese characters of the second level |
Among 1-1 to 94-94, other characters than the above are all considered machine dependent characters.
Pictogram of NTT DoCoMo imode and Patent application HTML allow some number enclosed within a circle.
136. BOM is included at the beginning of the document.
Control code called BOM(Byte Order Mark) is included at the beginning of the document. UTF-8 BOM are 0xEF 0xBB 0xBF. This does not deduct any point.
137. Better specify encoding in XML declaration in XHTML. *3*
XHTML Media Types(J) strongly recommends you to specify encoding in XML declaration in XHTML. For application/xhtml+xml media type, this is the same when CHARSET is specified in HTTP response header.
138. Charset is set to `XXXX`, but the actual code seems YYYY. *5*
Character encoding is specified with CHARSET, but the HTML is actually written in a different encoding. The document will not be read by browsers which understand CHARSET correctly. This only checks Japanese encoding (JIS, EUC, Shift JIS, UTF-8). Encoding specified in XML declaration has a priority. Furthermore, CHARSET specified in HTTP response header has a priority over it.
This checkpoint is not enabled when HTML is specified by DATA area instead of URL.
139. Charset is set to `XXXX` in HTTP response header, but `YYYY` is specified in <META> . *5*
CHARSET specified in HTTP response header and in <META> do not match. Or, it does not match with encoding specified in XML declaration. This only checks Japanese (JIS, EUC, Shift JIS, UTF-8).
This checkpoint is not enabled when HTML is specified by DATA area instead of URL.
140. HTTP response header does not contain CHARSET. *3*
CHARSET should be specified in HTTP response header. XHTML Media Types(J) strongly recommends that as well. However this is a server side problem. This checkpoint is enabled only when it is via HTTP.
141. CONTENT-TYPE specified in <META> is not text/html. *5*
text/html is an identifier which indicates what type of data called Internet Media Type it is. This is managed by IANA(Internet Assigned Numbers Authority). HTML is text/html. This alerts you if you use colon as a delimiter by mistake instead of semi-colon.
Please note that "text/xhtml" is not for XHTML, such a media type does not exist.
142. Media type specified in HTTP response header is `xxxx/xxxx`, but `yyyy/yyyy` is specified in <meta>. *5*
Currently available media types for HTML are text/html and application/xhtml+xml. HTTP response header and <meta> have a different media type respectively. However, application/xhtml+xml should not have <meta http-equiv> in the first place.
143. Media type xxxx/xxxx should not be specified for YYYYYY. *3*
According to XHTML Media Types(J), it is prohibited to specify application/xhtml+xml for HTML, and it is not recommended to specify text/html for XHTML1.1. No warning for XHTML1.0.
144. <meta http-equiv> should not be written for application/xhtml+xml. *4*
According to XHTML Media Types(J), it is not recommended to write <meta http-equiv> for the document whose media type is set to application/xhtml+xml.
145. <META HTTP-EQUIV="CONTENT-TYPE"> is present in the NNth line too. **
This is not technically wrong, but you still better write it just once.
Same warning for HTTP-EQUIV="REFRESH".
146. <META HTTP-EQUIV="CONTENT-XXXX-TYPE" CONTENT="～"> should be specified in <HEAD>～</HEAD> when using <TAG>. *3*
HTML4.01(J)says that base script language should be clearly specified in <META> when using script.
<META http-equiv="Content-Script-Type" content="text/javascript">
This should be declared before <SCRIPT>. The individual language specified for <SCRIPT> does not necessarily have to be the same language.
Also, base language should be clearly specified when using stylesheet as well.
<META http-equiv="Content-Style-Type" content="text/css">
This checkpoint is only for <STYLE> and there is another check for STYLE attributes embedded in other tags.
147. ATTR attribute requires <META HTTP-EQUIV="CONTENT-XXXX-TYPE" CONTENT="～"> in <HEAD>～</HEAD>. *5*
For script event handling such as ONCLICK and ONBLUR, you have to specify the language in <META>, which is stated in HTML4.01(J). For Javascript,
<META http-equiv="Content-Script-Type" content="text/javascript">
this kind of declaration should be included.
When you use STYLE attributes for different <META>s, the style languages have to be specified as described in HTML4.01(J). For CSS,
<META http-equiv="Content-Style-Type" content="text/css">
this kind of declaration should be included.
148. <META> can not have both HTTP-EQUIV and NAME attributes. *5*
According to HTML4.01(J), HTTP-EQUIV attribute is used as an altenative to NAME attribute. Thus, they can not be specified together.
149. <META> CONTENT attribute requires either HTTP-EQUIV attribtue or NAME attribute. *5*
<META> requires CONTENT attribute and HTML4.01(J)says that META element should be specified with both name and value. That means either HTTP-EQUIV attribute or NAME attribute is required besides CONTENT attribute. DTD is unable to express this kind of order.
150. ATTRA attribute should be specified together with ATTRB attribute. *3*
Regarding script event handling, it is recommended to use the following attributes in a pair to ensure non-machine dependence by Techniques for Web Content Accessibility Guidelines4.12.2(J).
| onmousedown | + | onkeydown | |
| onmouseup | + | onkeyup | |
| onclick | + | onkeypress | |
151. Lorem Ipsum is simply dummy text of the printing and typesetting
WAI says web pages should not be automatically updated/reloaded by REFRESH. This is mainly for respecting the users' will.
152. <META HTTP-EQUIV="REFRESH" CONTENT="～"> should be used together with an equivalent link to it. *3*
For user agents which do not support automatical alteration, normal links should be provided as well, according to HTML4.01(J). However, WAI does not recommend automatial update by REFRESH in the first place.
There is the following example stated in HTML4.01(J).
<META http-equiv="REFRESH" content="3,jump.html">
In reality, however, the following way is popular.
<META http-equiv="REFRESH" content="3;URL=jump.html">
We are not sure which one or both is/are correct. Another HTML-lint 5 distinguishes them by a delimiter, "," or ";".
153. It is safe to enclose all of the elements in <SCRIPT>～</SCRIPT>. **
<SCRIPT>～</SCRIPT> includes some syntactical text (e.g. JavaScript) which is not related with HTML. The number of the browsers which do not understand <SCRIPT> tag is not small, thus JavaScript programming etc. will be directly displayed without conversion. Therefore, the following way is used for JavaScript.
<SCRIPT type="text/javascript">
<!-- COMMENT A
JavaScript Statement...
// COMMENT B -->
</SCRIPT>
Please note that the --> at the end of the comment is after //. You will get an syntax error if you write --> without //. HTML4.01(J) says that the -- should not be written in a comment. This may be because the -- in CDATA is taken into consideration.
Commenting out does not work as intended in the following way.
<SCRIPT type="text/javascript">
//<!-- COMMENT A
JavaScript Statement...
// COMMENT B -->
</SCRIPT>
The first // will remain.
Except JavaScript, the followings are for Tcl and VBScript.
<SCRIPT type="text/tcl">
<!-- COMMENT A
Tcl Statement...
# COMMENT B -->
</SCRIPT>
<SCRIPT type="text/vbscript">
<!-- COMMENT A
VBScript Statement...
' COMMENT B -->
</SCRIPT>
This error is displayed for <STYLE>～</STYLE> as well. In this case, you can just enclose the content with comments.
<STYLE type="text/css">
<!-- /* COMMENT A */
Syle Statement...
/* COMMENT B */ -->
</STYLE>
As for XHTML1(J), the content of <SCRIPT> and <STYLE> has been changed from CDATA to #PCDATA, so it is not enough just to apply this technique. You can use Marked section.
Please see the necessity of external file.
154. Do not write `</` directly in <SCRIPT>～</SCRIPT>. *6*
According to SGML, <SCRIPT> and <STYLE> tags do not end with </SCRIPT> or </STYLE> tags. They end with </. Therefore, in JavaScript, charaster strings including "</" (e.g. "</A>") are not allowed to be written directly. You have to make some processing to escape.
For example "<EM>This will work</EM>" (quote from HTML4.01(J)), you can escape it as below in case of JavaScript:
<SCRIPT type="text/javascript">
document.write ("<EM>This will work<\/EM>")
</SCRIPT>
in case of Tcl:
<SCRIPT type="text/tcl">
document write "<EM>This will work<\/EM>"
</SCRIPT>
use Chr() function in case of VBScript:
"<EM>This will work<" & Chr(47) & "EM>"
In short, you just have to ensure that "</" is not used. The following way is also valid for JavaScript.
"<EM>This will work<"+"/EM>"
You have to do the same processing for comments as well.
// <EM>comment</EM>
This is not allowed.
155. External script should be provided for `XX` in <SCRIPT>～</SCRIPT>. *3*
External file should be provided when you write the following characters inside <SCRIPT> and <STYLE>.
< | |
& | |
]]> | |
-- |
This is because the specification of <SCRIPT> and <STYLE> has been changed in XHTML as described in XHTML1.0 C.4.
This warning does not deduct any point except for XHTML.
156. Comment in <SCRIPT>～</SCRIPT> is handled as an actual comment. *3*
In XHTML, the content of <SCRIPT> and <STYLE> is #PCDATA. Comments are considered as comments, thus the old technique is unavailable. You should use external script/style file instead.
157. <SCRIPT> is present without <NOSCRIPT>. *4*
You will be alerted when <SCRIPT> is present without <NOSCRIPT> depending on the HTML version.
This rule is defined by WAI. However, this <NOSCRIPT> tag was later added, so some of the old browsers including Mozilla2.0 do not support <NOSCRIPT>, while they do support <SCRIPT>. In that case, the content of <NOSCRIPT> will be displayed.
WAI says that <NOSCRIPT> should be provided only for a script having important information or features. This does not deduct any point.
158. <TITLE> content better be less than 64 characters. *3*
Technically, there is no restriction of character count, but some browsers cut it if it is too long. RFC1866(J) says that at least 64 characters should be allowed. There is no mention in HTML4.01(J) about this.
159. Color specified in <BODY> is incomplete. XXX and YYY attributes should be also included. *3*
In many of the HTML, attributes which can be used to specify color in <BODY> are BGCOLOR, TEXT, LINK, VLINK and ALINK. But in some of the browsers including Mozilla, you are allowed to ignore the attributes. For example, if you just specify like this "<BODY bgcolor="white">" and the browser is set to "white-on-black", the HTML is then invisible. To avoid this, you should specify colors for the whole. There is a similar note in HTML4.01(J) as well.
This issue could occur for stylesheet too, although Another HTML-lint 5 does not check contents of stylesheets.
<BODY style="background: #FFFF00">
This is not checkable.
160. BGCOLOR attribute should be specified together with BACKGROUND attribute in <BODY>. **
When a background image is specified in <BODY>, the text color is supposed to be a visible color on it. However, without BGCOLOR attribute, the text may get invisible depending on the browser setting.
161. Same color is specified for <TAG ATTR> and <TAG BGCOLOR>. *3*
For instance,
<BODY background="hogehoge.gif" bgcolor="#FFFFFF" text="#FFFFFF">
in this case, if the background image is not displayed, the text will be unreadable/invisible. This checkpoint does not care about background images. In addition,
<BODY bgcolor="#FFFFFF">
<TABLE bgcolor="#FF0000">
<FONT color="#FFFFFF">
this is unreadable.
162. Brightness difference and color difference between <TAG ATTR> and <TAG BGCOLOR> are not enough. *3*
Brightness difference and color difference between background and foreground are not enough. This check is based on Techniques For Accessibility Evaluation And Repair Tools. For instance,
- Color brightness is determined by the following formula: ((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000
- Color difference is determined by the following formula: (maximum (Red value 1, Red value 2) - minimum (Red value 1, Red value 2)) + (maximum (Green value 1, Green value 2) - minimum (Green value 1, Green value 2)) + (maximum (Blue value 1, Blue value 2) - minimum (Blue value 1, Blue value 2))
The rage for color brightness difference is 125. The range for color difference is 500.
You can refer to color check (by Mr. Kanzaki) as well.
The relation with backgroud images or colors specified in stylesheets is not checkable.
163. Luminance ratio between <TAG ATTR> and <TAG BGCOLOR> is not enough. *3*
Luminance ratio between background color and foreground color is not enough. This check is based on Web Content Accessibility Guidelines 2.0.
- the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white R' = (R <= 0.03928)? R/12.92: ((R+0.055)/1.055)2.4
- Brightness: R'×0.2126 + G'×0.7152 + B'×0.0722
- Bigger luminance ratio:L1, Smaller luminance ratio:L2, (L1+0.05)/(L2+0.05)
A contrast ratio of at least 4.5:1 for level AA and a contrast ratio of at least 7:1 for level AAA required. There are some exceptions defined by WCAG. The relation with backgroud images or colors specified in stylesheets is not checkable.
164. <TAG> ID attribute value `XXXX` is already used in the NNth line. *5*
The same value of ID attribute can not be present in a HTML. The value is not case sensitive in HTML but is in XHTML.
165. <TAG> ATTR attribute ID `XXXX` in the NNthe line is not defined. *5*
In HTML4.01, some values such as <LABEL> FOR attribute value have to be specified as ID attribute of other tags.
For NTT DoCoMo imode, ID specified in <A IJAM> has to be supported by <OBJECT ID>.
166. <TAG> NAME attribute value `XXXX` is already used in the NNth line. **
<FORM> elements such as <INPUT> and <TEXTAREA> can be passed to CGI etc. as a pair of the VALUE attribute value and the NAME attribute data. Like TYPE=TEXT, if two or more elements of the same name exist within one FORM, they are undistinguishable by the CGI side.
However, in HTML4.01(J) regarding form control except check box and the radio button, there is no reference about the uniqueness of the NAME attribute. But there are such examples in RFC1866(J) 8.1.2.7 with the same NAME SUBMIT. That is,
<INPUT type="submit" name="command" value="Search">
<INPUT type="submit" name="command" value="Replace">
are acceptable. Also, when the NAME attribute is omitted, it seems possible to take the same value with the TYPE attribute, but that is uncertain. If the NAME attribute is not present, this element does not contribute a form field.
You will not be alerted regarding TYPE=RADIO/CHECKBOX/SUBMIT/RESET/BUTTON/IMAGE and HIDDEN where the value of the VALUE attribute is fixed.
167. Do not write the text except the blank right after <TAG>. *3*
The ordinary text can be written right after<FIELDSET>, but you cannot write anything but a blank here. This is commented in DTD. The following is a quote from HTML4.01 DTD.
#PCDATA is to solve the mixed content problem,
per specification only whitespace is allowed there!
168. CHECKED attribute specified in <INPUT TYPE="RADIO"> is already specified in the NNth line. *5*
You can check only one radio button of the same name that is the radio button of the same group in <INPUT type="radio">.
169. None of the <INPUT TYPE="RADIO" NAME="YYYY">s has CHECKED attribute. *3*
None of the <INPUT type="radio">s of the same group is checked.
It is said that you should check any of them, according to HTML4.01(J).
170. None of the <OPTION>s has SELECTED attribute. *3*
None of the <OPTION>s of the same <SELECT> has SELECTED attribute.
It is said that you should check any of them, according toHTML4.01(J).
171. <OPTION> SELECTED is already specified in the NNth line. You should specify MULTIPLE attribute for <SELECT> in the MMth line. *5*
You have to specify MULTIPLE attribute with <SELECT> tag to add multiple SELECTED attributes to <OPTION>.
With NTT DoCoMo imode 1.0, you can not specify multiple SELECTED attributes.
172. <OPTION> which can be specified for a single <SELECT> is up to 20. *5*
With NTT DoCoMo imode 1.0, you can specify up to 20 options using <OPTION>.
173. Better specify the text used as an initial value as <TAG> . *3*
According to WAI, it is recommended to write some text as an initial value for <INPUT type="text"> and <TEXTAREA>. As the reason, the possibility is mentioned of the browsers that cannot handle correctly if it is empty.
174. Better specify TYPE attribute for <BUTTON>. *3*
ISO/IEC 15445 says that you should not omit the TYPE attribute of <BUTTON>.
175. <IMG> used for <BUTTON> can not have USEMAP attribute. *5*
HTML4.01(J)says that when you stick an image on <BUTTON>, you are not allowed to make it image map. As for it, ISMAP is also the same.
176. <TAGA> can not be present here. *5*
There are several methods to label form control, but one of them is to include form control in a <LABEL> element directly. You can include only one control in <LABEL>～</LABEL>. Please see HTML4.01(J).
177. You must specify form control in <LABEL>～</LABEL> where the FOR attribute is not included in. *5*
<LABEL> is to add an additional attribute for form control, and it must be connected with one of the form controls. One method is to specify it as the element of <LABEL>, the other method is to relate it with the ID attribute of form control by FOR attribute. That means <LABEL> without the FOR attribute must include form control in the contents of the element.
178. <TAG> ID attribute value and <LABEL> FOR attribute value in the NNth line are different. **
When you write form control in the element of <LABEL>, the form control is to be connected with the <LABEL>, but there is not a reference in HTML4.01(J) how it is taken when an FOR attribute and an ID attribute are dditionally specified.
The followings are possible combinations.
- When there is neither FOR nor ID
It seems that this label is not related with form in many browsers (MSIE5 to 6, Netscape3 to 7, Opera6 etc.) although it seems there is no problem as spec.<LABEL>
<INPUT>
</LABEL> - When there is only FOR
It is considered that a label is connected with form control having other ID="A", then the form control written to the contents is no longer related with a label, and is considered not to be desirable.<LABEL for="A">
<INPUT>
</LABEL> - When there is only ID
Form control is related with an outside label and a label with other FOR="A." It is not wrong to relate two or more labels with one form control.<LABEL>
<INPUT id="A">
</LABEL> - When ID matches FOR
Although it is redundant, it seems fine.<LABEL for="A">
<INPUT id="A">
</LABEL> - When ID and FOR do not match
It make no sense to write form control as a lavel element, and it seems not desirable.<LABEL for="A">
<INPUT id="B">
</LABEL>
This interpretation may be wrong. Please point it out at support@heartcore.co.jp.
179. Better specify a TABINDEX attribute for <TAG>. *3*
For better accessibility, it is recommended in WAI to add TABINDEX to <INPUT>, <TEXTAREA>, <BUTTON> and <SELECT> of the form control and to specify the order. This does not deduct any point.
WAI says that TABINDEX attribute should also be added to <A> conditionally, but that is removed here.
180. Better specify ACCESSKEY attribute for <TAG>. *3*
For better accessibility, WAI recommends to prepare keyboard short-cut using ACCESSKEY attribute for link tags such as <A>, <LABEL>, <LEGEND> and <AREA>, as well as form controls such as <INPUT>, <TEXTAREA> and <BUTTON>. This does not deduct any point.
<A accesskey="C" href="doc.html">XYZ company home page</A>
You cannot specify multiple characters like accesskey="XYZ".
About the uniqueness of the key to appoint, it is not described in HTML4.01(J). Depending on a user agent, the control having the same access key seems to be implemented to move in them in sequence. However, 17.11.2(J) says that <A> flies to a link place immediately and the state of a radio button also changes immediately. That means the access key is intended to cause an action and not intended to move the control. Strangely, there is no argument when the same access key is specified.
In the form control related with the label, even if there is no ACCESSKEY attribute in the form control itself, please note that what is necessary is just to be on a label.
The combinations for specifying ACCESSKEY attribute for connected label and form control are as follows.
- When it is specified for neither of them
You must apecify ACCESSKEY attribute for either of them.<LABEL>
<INPUT> - When it is specified only for label
No problem.<LABEL accesskey="A">
<INPUT> - When it is specified only for form control
No problem.<LABEL>
<INPUT accesskey="A"> - When the same key is specified for both
It is redundant, but seems fine.<LABEL accesskey="A">
<INPUT accesskey="A"> - When different keys are specified respectively
It may be possible to put a focus into the form control by either key, but this might be incorrect. No point deduction.<LABEL accesskey="A">
<INPUT accesskey="B">
181. Better specify TITLE attribute for <TAG>. *3*
For better accessibility, WAI recommends to write TITLE attribute for <ABBR> and <ACRONYM>.
This does not deduct any point.
182. <OBJECT> needs equivalent contents. *4*
It is recommended to write suitable explanation for the contents of <OBJECT> element as below.
<OBJECT data="magnifyingglass.gif" type="image/gif">Search</OBJECT>
This is mentioned in Techniques for Web Content Accessibility Guidelines 4.7.1(J) and 4.8.1(J).
183. It is not recommended to write both ALT attribute and equivalent contents in <APPLET>. *3*
It is recommended to write suitable explanation for the contents of <APPLET> element in the same way as <OBJECT>. However, <APPLET> has ALT attribute, so it makes browsers confused to write both ALT attribute and explanation. Techniques for Web Content Accessibility Guidelines 4.8.1(J) states that only one of them should be written.
Please also note that <APPLET> is not a recommended tag in HTML4.01.
184. Specifying the character string of only a blank as the ALT attribute of <TAG> is not recommended. *3*
Techniques for Web Content Accessibility Guidelines 5.6.1(J) prohibits the use of blank ALT attribute like below.
my poem requires a big space<IMG src="10pttab.gif" alt="
">here
Another HTML-lint 5 always checks it not only in the middle of the sentence.
185. Better specify ALT attribute for <TAG>. *4*
There are many browsers which cannot display an image. Also, some browsers are set not to read an image automatically. In these case, if there is appropriate comment on what kind of image is present there, it helps for the users to read the text. Please note that the empty ALT alt="" may be effective in some cases. Please see WAI(J).
This warning is also output for other tags besides <IMG>, but ALT attribute is almost a required attribute in HTML4.01.
<INPUT type="image"> is used to display image button but did not have ALT attribute untill HTML4.0.
This is defined in WAI for better accessibility.
186. WIDTH and HEIGHT attributes should be specified for <TAG>. *
Even if a browser does not go to really read an image when the size of the image is given, the browser can lay out the other texts part. That means it helps for network to reduce the load and to display the content rapidly.
<INPUT type="image"> is used to display image button, but does not take WIDTH or HEIGHT attribute (even in HTML4.01). Thus, it has to go read an image.
This does not deduct any point.
187. ISMAP and USEMAP attributes can not be specified together for <IMG> . *3*
In ISO/IEC 15445, it is written clearly that you can not specify both ISMAP and USEMAP for <IMG>. Although there is not such a mention in HTML4.01, this warning is applied for every HTML version.
188. Better use client side image map instead of server side image map for <IMG ISMAP>. *4*
As there is various inconvenience in audio output when using server side image map, it is strongly recommended to use client side image map in WAI.
189. SUMMARY attribute should be specified for <TABLE> . *3*
For better accessibility, WAI recommends to add summary using SUMMARY attribute for <TABLE>.
This is a required attribute in ISO/IEC 15445, and another warning is provided.
190. ABBR attribute should be specified for <TH>. *3*
For better accessibility, it is recommended in WAI to add a short form of the header label using ABBR attribute to <TH>. However, if the header label is originally in a short form, adding ABBR attribute means nothing, but such an identification is not possible in Another HTML-lint 5. No point deduction.
191. You should not specify SPAN attribute in <COLGROUP> having <COL> as an element. *3*
It is written in HTML4.01(J) that SPAN attribute of COLGROUP having COL as an element is ignored.
As for ISO/IEC 15445, it is banned strictly.
192. <TAGA> COLSPAN attribute and <TAGB> ROWSPAN attribute in the NNth line overlap. *5*
The following is an example described in 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>
Cell "5" and cell "7" is overlapping.
193. There is <FRAMESET> tag, but not <NOFRAMES> tag. *3*
<NOFRAMES> should be written for browsers which do not support frame. Please also ensure <NOFRAMES> is present in a right place in a correct spelling. Particularly, S seem to often fall out like <NOFRAME>.
The following is gramatically correct but is nonsense.
<NOFRAMES>
<BODY>
<P>Please use Netscape to see this page. </P>
</BODY>
</NOFRAMES>
Even with this message, the person cannot necessarily follow directions.
194. SRC attribute of <FRAME> cannot specify URI `XXXX` pointing at oneself. *5*
According to HTML4.01(J), in SRC attribute of <FRAME>, it is forbidden to specify URI pointing at oneself.
<FRAME src="#same_document">
this is obviously wrong, but
<FRAME src="http://www.uso800.ac.jp/same_document.html">
in this case, Another HTML-lint 5 is unable to judge whether this is the same as oneself.
195. It is not recommended to specify images directly with SRC attribute of <FRAME>. *4*
WAI forbids specifying image etc. directly in <FRAME SRC>. According to Techniques for Web Content Accessibility Guidelines 4.10.4(J), FRAME should contain only HTML document.
This checkpoint is enabled only when it checks if URI exists.
196. TITLE attribute should be specified for <FRAME>. *4*
For better accessibility, It is written in WAI that TITLE attribute is always required in <FRAMESET> and <FRAME>.
197. <TAG> ATTR attribute frame target name `XXXX` is already specified in the NNth line. **
You are not allowed to put the same names to a frame target.
198. <TAG> ATTR attribute frame target name `XXXX` is reserved. *3*
The following frame target names are reserved in HTML4.01(J).
- _blank
- _self
- _parent
- _top
You can not put these names to a frame target. Please see the next warning for more information.
199. It is safe to write frame target name `XXXX` of <TAG> ATTR attribute in lower case. **
Frame target name is basically not case sensitive, so
<FRAME target="_top">
and
<FRAME target="_TOP">
are supposed to be the same, but some browsers consider them as different targets. You better use lower case to write the reserved frame target.
200. <TAG> ATTR attribute frame target name `XXXX` is not correct. *3*
It is written in HTML4.01(J) that frame target name must start with alphabetical character, otherwise the name is ignored. However, this is a very severe restriction and seems a preventive measure to address the reservation names which may increase in the future. For browsers that implemented a frame prior to HTML4.0 such as Mozilla, this restriction does not seem to take effect.
201. <TAG> is a physical font tag. You better use a logical tag instead. *3*
There are a physical tag and a logical tag as character font ornamentation. A physical tag is a direct tag such as <B> and a logical is a semantic tag such as <EM>. In terms of SGML, you should try to use semantic tags as much as possible, which is described in WAI as well. No point will be deducted.
In Laura Lemay's HTML book, <B> is used abundantly.
202. <P> is a tag for paragraphs. The tag to start a new line is <BR>. **
This warning is displayed when <P> is present at the end of line. <P> is not a tag to start a new line. Writing <P> at the end of line is years ago even before HTML2.0. In RFC1866(J), it is defined as a tag for paragraphs with ending tag.
203. Many <BR>s are continuing. **
When <BR> is used for cosmetic purpose in defiance of document structure, many <BR>s are present sequentially. Please do not change them like <BR> <BR> to avoid this warning.
Some of the browsers including Lynx may collect those continuous <BR>s into one.
204. Do not include a tab in <PRE> in the NNth line. *3*
It is strongly requested by HTML4.01(J) to avoid writing a tab character in <PRE>～</PRE>. A tab character is usually replaced with a blank character, but it deos not necessarily work as expected. In short, that is against the purpose of preformatted <PRE>.
205. <Hn> follows <Hm> in the NNth line, which is not desirable. *3*
HTML does not have the structure to express a chapter and a section directly, but has a tag for heading <H1>～<H6> instead. About the appearance order of these relations, there is originally no restriction. This checkpoint is just to alert you that something might be wrong for example when <H4> follows <H2>. However such a way of using heading tags is not recommended by RFC1866(J).
Also, please remember that these heading tags are not provided for character size adjustment.
This rule is defined in WAI for better accessibility.
206. ALT attribute of <IMG> in <Hn>～</Hn> should have some value. 。 **
This alerts you if the heading image is specified with empty ALT attribute as below.
<H1><IMG src="introduction.png" alt=""></H1>
For such an image, WAI mentioned about <A>, but not about headings. However, it is still not good to leave ALT attribute empty as well as <A>.
207. Better specify ACCESSKEY attribute for <A>. *3*
Please refer to the similar warning for <INPUT> etc. This does not deduct any point.
This warning is for <A>, while the above one is for others. Regarding <A>, WAI says the important links
need to have an ACCESSKEY attribute, which is not required to be specified for all of <A>. Another HTML-lint 5 is unable to tell which link is important.
208. Use a suitable character as a delimiter between links. *3*
For better accessibility, it is recommended by WAI to delimit links using some printable character (including blank character). For instance,
<A href="next.html">Next</A><A href="prev.html">Previous</A>
this is not recommended.
<A href="next.html">Next</A>|<A href="prev.html">Previous</A>
or
<A href="next.html">Next</A>
<A href="prev.html">Previous</A>
is recommended.
209. Write some explanation in <IMG> の ALT attribute of link image. *3*
You will be alerted when a image used for link has an empty ALT attribute as below.
<A href="routes.html"><IMG src="topo.gif" alt=""></A>
WAI prompts you to write some equivalent explanation for this kind of images.
210. <IMG> ALT attribute value `D` is not recommended. Use LONGDESC attribute instead. *3*
This technique called D-link is out of date and is not recommended to use. Please refer to Techniques for Web Content Accessibility Guidelines 3.2.2(J) and 4.7.2(J) for details.
211. Anchor `XXXX` of <A> links to a different place in the NNth line. *3*
According to Techniques for Web Content Accessibility Guidelines 4.6(J), it is not desirable to link to different places using the same anchor text as below.
<A href="http://www.everything.org/">APPLEBANANA</A>
<A href="http://www.uso800.ac.jp/~k16/everything/">APPLEBANANA</A>
If you have to have such links, different TITLE attributes should be used.
<A href="http://www.everything.org/" title="APPLE">APPLEBANANA</A>
<A href="http://www.uso800.ac.jp/~k16/everything/" title="BANANA">
APPLEBANANA</A>
212. It is not desirable to use `here` etc. as an anchor of <A>. *3*
According to Techniques for Web Content Accessibility Guidelines 4.6(J), for example, visually handicapped people may read only link parts. In that case,
Click <A href="info.html">here</A> for more info.
the above link does not help. The anchor text should be more meaningful sentence. You will be also alerted if you use "this website" or "this page" etc. as an anchor text. Please contact us at support@heartcore.co.jp when the normal anchor text is detected as an error.
Laura Lemay's HTML book and Style Guide for online hypertext(J) also explains why such anchor texts are not desirable. They are not recommended in WAI either. This is called This is called HERE syndrome.
In additin, it is said that "Click" is not a good anchor text either because clicking is not the only way to follow links.
213. It is not desirable to use `here` etc. for the value of the ALT attribute of <IMG> as an anchor of <A>. **
If "this" etc. is specified as the ALT attribute which expresses the contents of the picture when a picture is used for an anchor, it is also regarded as HERE syndrome.
214. Anchor `XXXX` of <A> includes blank character. *3*
Although any kind of characters are allowed to be used as an anchor name, but still a blank character is better not be used. Please see When the character which is not safe for an anchor name is used as well.
Since HTML4.01(J), you are no longer allowed to use any kind of characters.
215. Unsafe character is included in anchor `XXXX` of <A>. *3*
Handling of the anchor name has delicate problems. You can specify anchor name (fragment ID) like the following.
<a name="foobar">
Please note that anything may be written as the value of a NAME attribute. On the other hand, to refer to this anchor, you can specify it with URI like below.
<a href="http://www.uso800.ac.jp/fake.html#foobar">
or
<a href="#foobar">
(RFC2396 clearly defines that this anchor name part is not a part of URI.) Since it specifies together with URI, the character which is not right as URI must not be used for an anchor name, but that contradicts the property of the NAME attribute. There is no problem if you name it only by a usable character as URI. For example, when you name it as "[baz]" and write it as below,
<a href="#%5Bbaz%5D">
this will not work well. According to RFC, %XX encoding can be used. However, for example, when you name it in Japanese using JIS like below,
<a href="#%1B$B$O$8$a$K%1B(B">
it will be like this.
Therefore, it is safer to use neither a strange character nor Japanese for an anchor name.
"%" is not treated an exception in RFC2396, but RFC1738 says it is not safe to use it for an anchor name.
In HTML4.01(J), it is written that the anchor name must be the ASCII character. In XHTML1.0(J), it is recommended to specify anchor name with a ID attribute instead of a NAME attribute. In XHTML1.1, it is abolished to specify it with a NAME attribute.
216. <A> anchor name is empty. **
This warning is displayed when you forget to specify anchor name.
<a href="http://www.uso800.ac.jp/fake.html#">
In the above example, there is no name behind "#".
217. <A> anchor name `XXXX` is present in the NNth line too. *5*
You are not allowed to put the same name to multiple places of one HTML.
<A name="girl">ABCDEFG</A>
<A name="girl">HIJKLMN</A>
Please see the next warning as well.
218. <A> anchor name `XXXX` is present in the NNth line. The case may not be distinguished. *3*
Although HTML4.01(J) requires the consistency of upper case and lower case for an anchor name, the fillowing example is considered incorrect.
<A name="popie">AAAAA</A>
<A name="POPIE">BBBBB</A>
ID attribute is not mentioned here. The case of ID attribute is not distinguished for the same reason as neither an element name nor an attribute name being distinguished. (SGML declaration(J) NAMECASE GENERAL YES). Since the value of a NAME attribute itself is distinguished, these anchors are valid respectively. It seems that this is daringly considered as an error for ID attribute to take over NAME attribute.
219. <A> anchor name `XXXX` is also used as ID attribute in the NNth line. *5*
In HTML4.01(J), the anchor name specified in <A name> and the ID attribute value of various tags are not allowed to be the same.
<A href="#APPLE">AAAAAAA</A>
<A name="APPLE">BBBBBBB</A>
<H2 id="APPLE">CCCCCCC</H2>
This warning is only for HTML4.0 or newer.
220. <A> anchor name `XXXX` is defined as ID attribute in the NNth line. *
<A href="#HOEE">
You can use a ID attribute to specify the anchor corresponding to the above like this
<H1 id="HOEE">
However, this is not supported in the old browsers.
XHTML1.0(J) recommends to use ID attribute instead of NAME attribute. In XHTML1.1, such a NAME attribute is abolished.
This warning is only for HTML4.0. No point deduction.
221. Value `YYYY` of the ID attribute has to be the same as value `XXXX` of the NAME attribute of <A> in the same tags. *5*
<A name="HYOEE" id="HYOEE">
The value of the ID attribute has to be the same as the NAME attribute in the same tag like above. This warning is only for HTML4.0. In XHTML1.1, such a NAME attribute is abolished.
222. Specify both a NAME attribute and ID attribute for <TAG>. *3*
Regarding anchor name, W3C has shifted it to ID attribute instead of NAME attribute.
ISO/IEC 15445 and
XHTML1.0(J)(Appendix C.8) recommend to specify both of them as a transitory measure, although they have to be the same value. In XHTML1.1, such a NAME attribute is abolished.
223. <TAG> ID attribute value `XXXX` should not include lower case. *3*
In ISO/IEC 15445, it is recommended not to use lower case for ID attribute value. ⇒
User's Guide to ISO/IEC 15445:2000(E) ISO-HTML
This is originally based on SGML standard and can be also applied for HTML4, but ISO-HTML describes clearly about this.
SGML declaration "NAMECASE GENERAL YES" does not only mean upper case and lowe case should be identified, but also lower case should be taken after converting to upper case. This rule is also applied to ID attribute, so in HTML4,
<a id="foo">
is taken as
<A ID="FOO">
However the rule is not applied to NAME attribute, so
<a id="foo" name="foo">
is taken as
<A ID="FOO" NAME="foo">
although it is contary to the regulation that NAME attribute and ID attribute must have the same value. In HTML4, you will be alerted if lower case is included in ID attribute. Please note:
<a id="foo">
to refer to the above,
<a href="#FOO">
it has to be like this. In reality, however, most of the browsers work normally with lower case fragment ID.
Since XHTML is case sensitive, this type of problem does not occur. When ID in HTML is referred to from XHTML, ID value is changed into a upper case, therefore it is required to refer it in upper case.
224. <A> anchor name `XXXX` is missing. *3*
When you write a link like below,
<A href="#shit">
the anchor name has to exist in the HTML and you will be alerted if it is missing. The name is case sensitive.
225. Anchor name `XXXX` of <A> is not referred to. *
It is not necessarily an error just because the specified anchor name is not referred to in the same HTML. It may be referred from other HTML. However, it could be an error such as wrong spelling. No point deduction.
226. <TAG> ATTR attribtue URI is empty. **
That means
<IMG src="">
is not good. But according to RFC1808, it is considered that it is the same as URI specified in <BASE> when URI is empty. When <BASE> is not present, it is considered thta it is the same as itself, so
<A href="">
in this case, it is linking to itself. However, it does not work in some browsers including Mozilla. In fact, there is an example like below using JavaScript
<A href="" onClick="this.href=pickupRandomURL()" onMouseOver=...>
227. Blank character is included in ATTR attribute URI 'XXXX' of <TAG>. *3*
It is not forbidden to include a blank in URI, but is not safe. The blank is expressed as %20 in URI.
228. <TAG> ATTR attribute URI `XXXX` includes `\`. Path delimiter has to be `/`. **
For URI, the directory delimiter is "/". You have to replace "\" (used in Windows etc.) with "/".
229. <TAG> ATTR attribute URI `XXXX` includes `~`. %7E is safer. *
In August, 1998, RFC1738 and RFC1808 was unified, and RFC2396 which defines the general syntax of URI was standardized. Before this, "~" (Tilde) was considered an unsafe character as URI, but it became an usable character in RFC2396. This "~" is often used as a prefix for an account like "http://www.uso800.ac.jp/~k16/". It can be written as "http://www.uso800.ac.jp/%7Ek16/" instead.
This warning does not deduct any point.
230. Unusable character `X` is included in ATTR attribute URI `XXXX` of <TAG>. It has to be %XX instead. *3*
General URI (Uniform Resource Identifier) is prescribed by RFC2396. Another warning comes out for other characters than ASCII code 20～7E. However, excluded characters among ASCII characters are shown in this RFC. The following characters are excluded. For a blank and "\", another warning is povided, and "#" is considered an anchor delimiter in http: scheme.
| Blank | %20 | |
" | %22 | |
# | %23 | |
% | %25 | |
< | %3C | |
> | %3E | |
[ | %5B | |
\ | %5C | |
] | %5D | |
^ | %5E | |
` | %60 | |
{ | %7B | |
| | %7C | |
} | %7D |
Some of the CGI specified by provider define "|" should be written as it is. In this case, replacing it with %7C does not work.
These characters are considered unsafe in RFC1738, but excluded in RFC2396.
231. Entity reference `&xx;` in URI of <TAG> ATTR attribute is unusable. *3*
Even if you write URI using entity reference like this,
<A href="<where>">
it is the same as "<where>". That is, < or > is not allowed to be used for URI, thus you can not use < or > either. When you necessarily have to write like < or >, it should be as below.
<A href="%3Cwhere%3E">
Also, like &image, when the parameter following & in the CGI call is incidentally the same as the defined entity reference, this warning may come out. The parameter delimiter in the CGI call should be &.
Character reference like ÿ is same. In this case, the included # is not considered an anchor delimiter.
232. Characters other than ASCII are contained in URI `XXXX` of the ATTR attribute of <TAG> . *5*
The character which can be used for URI is only a character of ASCII code 20 to 7E. Kanji and Katakana can not be used.
233. Scheme name `XXXX` specified as URI of the ATTR attribute of <TAG> is incorrect. *5*
According to RFC2396, the scheme name which can be specified as URI has to consists of lower case alphabetical character, digit, plus"+", period "." and hyphen "-". It is also written that upper case alphabetical character can be considered lower case.
234. Use lower case to specify scheme name `XXXX` of URI of the ATTR attribute of <TAG>. **
Upper case alphabetical character is not included in the characters which can be used for the scheme name specified as URI, but according to RFC2396, it is allowed to regard upper case as lower case.
235. Unknown scheme name `XXXX` is specified as URI of the ATTR attribute of <TAG>. **
Not all of the schemes that can be specified as URI are not covered. If you get an error for the correct scheme, please contact us at support@heartcore.co.jp. In most cases, it is a spelling error.
RFC1738 includes the followings.
http:ftp:file:gopher:mailto:news:nntp:telnet:wais:prospero:
RFC (probably) does not have a scheme for security server such as https:. Different schemes are defined by other RFCs, but they are omitted here.
Mozilla etc. includes
view-source:javascript:/livescript:/mocha:about:montulli:
and so on. For more information regarding these Mozilla specific schemes, please see Netscape Tips&Tricks etc.
236. URI `XXXX` of the ATTR attribute of <TAG> may be unable to be referred on the Internet. **
When you specify a scheme pointing to a local file such as file: for URI in HTML to show on the Internet, the file is unable to be referred.
This checkpoint is not enabled when HTML is specified by DATA area instead of URL.
237. Scheme `XXXX` of ATTR attribute URI of <TAG> is unusable. *3*
In TTNet doti, only http: mailto: tel: can be used.
238. Scheme `javascript` specified as URI of the ATTR attribute of <TAG> is not recommended. *3*
Techniques for Web Content Accessibility Guidelines 4.12.1(J) says it is not recommended to use "javascript" for URI in consideration for users who can not use script. In reality, however, there are some javascript schemes which are not necessarily restricted. For example, in case it is just nice-to-have feature. No point deduction.
239. URI `XXXX` of the ATTR attribute of <TAG> is a incorrect form. *3*
Although the form of URI is defined by RFC2396, it just defines the gereral URI syntax, but not the syntax for individual scheme. Another HTML-lint 5 checks individual schems which are defined by RFC1738 etc.
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]
However, the above syntax are skipped considerably and not technically correct. Please refer to the followings for the correct syntax. Another HTML-lint 5 does not necessarily reflects all except RFC1738. Also, there are remediation information for these in 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)
The characters which can be used for each scheme are slightly different. You are not allowed to write the characters restricted by RFC2396 directly or using entity reference for URI. These characters all have to be expressed like %3C.
The followings are some of the wrong examples.
http:~k16/hogehoge.html
http:/~k16/hogehoge.htmlhttp://.uso800.ac.jp/~k16/hogehoge.htmlhttp://fake_univ.uso800.ac.jp/~k16/hogehoge.htmlhttp://bogus-.uso800.ac.jp/~k16/hogehoge.htmlhttp://geregere:password@uso800.ac.jp/~k16/hogehoge.htmlhttp://www.uso800.ac.jp/cgi-bin/hogehoge.cgi?foo=bar|zoo=penguinhttp: //www.uso800.ac.jp/file://c:/homepage/index.html
file://c:\homepage\index.htmlmailto:geregere.uso800.ac.jpmailto:ｇｅｒｅｇｅｒｅ＠ｕｓｏ８００．ａｃ．ｊｐmailto:Killer Panther <geregere@uso800.ac.jp>news://news.uso800.ac.jp/uso800.www.authoringnews:123/news.uso800.ac.jpnews:123@.news.uso800.ac.jp
news:uso800@192.168.0.1
It is not the original purpose, but some people use a trick of writing a text behind mailto: etc. This seems to have aimed at the effect that the text was displayed on a status line, when the mouse is over on it in Mozilla etc.
240. URI `XXXX` of the ATTR attribute of <TAG> should end with `/`. **
There are various schemes you can use for URI, such as http, ftp and mailto etc. But only http/https schemes are checked. The example of http scheme URI is like below.
http://host:port/path
Default HTML is omittable for most of the servers, so
http://www.uso800.ac.jp/fake/index.html
can be
http://www.uso800.ac.jp/fake/
(only if defualt HTML is index.html). But if you write it as
http://www.uso800.ac.jp/fake
it will take time to display the page as the "fake" will be first considered a file and then "index.html" will be checked. Therefore, "/" should be added to the URI which points to a directory. However, Another HTML-lint 5 does not check if the URI actually exist (unless enabled), it is not possible to output this kind of warning.
http://www.uso800.ac.jp/%7Ek16
http://www.uso800.ac.jp/~k16
In the above case, you will be alerted.
When you enable Another HTML-lint 5 to check if URI exists, it may also check if "/" is required. Currently this check is only available when LWP is used get URI.
In addition,
http://www.uso800.ac.jp
this is not wrong. "/" is omittable when only a host name is provided.(RFC1738, RFC1808)
241. URI `XXXX` of the ATTR attribute of <TAG> may not be evaluated correctly. **
The URI starting with // is a correct URI, but it may not be evaluated correctly.
242. URI `XXXX` of the ATTR attribute of <TAG> is specified as `YYYY` in the NNth line. *
For example,
http://www.uso800.ac.jp/bogus/
and
http://www.uso800.ac.jp/bogus
one of them must be wrong. this check is only for http/https scheme.
It is possible to point to different resources by addind/removing "/".
http://www.perl.com/CPAN/
http://www.perl.com/CPAN
Actually these two URI used to point to the different resources (note: currently they point to the same resource as of 2004/12)). However, this seems a rare case, so the warning is still displayed with no point deduction.
243. URI `XXXX` of the ATTR attribute of <TAG> is specified as `YYYY` in the NNth line. *
Assuming that many of index.html(s) are default HTML, this alerts you when for example the following two URI exist in the same HTML.
http://www.uso800.ac.jp/fake/index.html
and
http://www.uso800.ac.jp/fake/
Since browsers are unable to judge if these are the same resource, they will be cached separately. It is not efficient. Only http/https scheme is checked.
244. Relative URI is specified in the NNth line before <BASE> HREF attribute. *5*
When specifying a HREF attribute in <BASE>, you can not use relative URI before it to relate with external.
In HTML4.01(J), all references are restricted. Please note it does not restrict the kind of resource. However, it is also written that <BASE> is effective only for relative URI. Another HTML-lint 5 just checks relative URI(s) which is present before <BASE>.
245. <BASE> HREF attribute URI must be specified by absolute position. *5*
HTML4.01(J) says that URI specified by the HREF attribute of <BASE> has to be a absolute position. So,
<BASE href="base.html">
is not allowed and has to be like below
<BASE href="http://www.uso800.ac.jp/bogus/fake/base.html">
246. There are still some texts after </HTML>. *6*
HTML ends when </HTML> appears. Some of the browsers can display even after </HTML>, but you should not expect.
247. In XXXXXX, HTML document must be less than NK byte. *5*
The limit size of HTML document is 2K byte for NTT DoCoMo imode (5K byte in 2.0) and 6K byte for J-SkyWeb. The limit size includes the size of image files used in the page, but it is checked only when URI existence check is enabled.
248. URI `XXXX` of the SRC attribute of <IMG> is not YYY. *5*
You can use only GIF images for NTT DoCoMo imode HTML document.
Also, J-SkyWeb HTML document allows only PNG images.
This is checked only when URI existence check is enabled.
249. The nest of <TAG> is too deep. The nest of <UL> and <OL> must be within three levels. *5*
J-SkyWeb HTML does not allow over three levels of nesting for <UL> and <OL> tags.
250. <TAGA> only can contain less than NN <TAGB>(s). *5*
For J-SkyWeb HTML, you are not allowed to write more than 99 <LI>s in <UL> and <OL>.
For NTT DoCoMo imode 4.0 HTML, you are not allowed to write more than 16 <PARAM>s in <OBJECT>.
251. XXXXXX must start with <HTML>. *5*
It is a strange rule, but a patent application document has to start with <HTML>.
252. XXXXXX must be written in Shift JIS. *5*
A patent application document has to be written in Shift JIS. Also, Shift JIS has to be used for NTT DoCoMo imode.
This checkpoint is not enabled when HTML is specified by DATA area instead of URL.
253. `■` can not be used for XXXXXX. *5*
A parent application document has a lot of rules for what kind of characters are accepted, but only the characters banned for user use are checked here. Some of the one-byte katakana etc. have been added as usable characters.
254. An invalid lower element *9*
Please refer to HTML 5 tag list for the list of permitted contents.
255. Inadequate attribute value *9*
Valid attribute value is wanted.
For instance,
The COORDS attribute of an AREA tag must follow the following rules：
-
shape = "rect" & coords = Rectangular coordinates # #
Specifies that the form of this hyperlink area on an image map is a rectangle.
Value:The list of four integers divided by comma, and it follows correctly in following order:- The integer showing the distance from the left end of the image to the left of rectangular in CSS pixel
- The integer showing the distance from the top end of the image to the top of rectangular in CSS pixel
- The integer showing the distance from the left end of the image to the right of rectangular in CSS pixel, and larger than the first integral value of this list.
- The integer showing the distance from the top end of the image to the bottom of rectangular in CSS pixel, and larger than the second integral value of this list.
-
shape = "circle" & coords = Circle coordinates # #
Specifies that the form of this hyperlink area on an image map is a circle.
Value:The list of three digits divided by comma, and it follows correctly in following order:- The integer showing the distance from the left end of the image to the center of a circle in CSS pixel
- The integer showing the distance from the top end of the image to the center of a circle in CSS pixel
- The non-negative integer showing the radius of the circle in CSS pixel
-
shape = "poly" & coords = Polygonal coordinates # #
Specifies that the form of this hyperlink area on an image map is a polygon.
Value:The list consisting of at least six integers and divided by comma, and the digits of the integers in the list are even number.
256. Inadequate MIME type *9*
MIME type syntax:
The media type defined by 2616 ； E.g.: text/css, text/css;charset=utf-8.
257. Inadequate LANG code *9*
Valid language codes： RFC 5646 language tag consists of ASCII alphanumeric character sub tags divided by hyphen. There are main tags which specify natural language (E.g: "en" for English) with the additional sub tag which adds the shortest ISO 639 language code and correctness. The most common additional sub tag type is a local sub tag which is the ISO 3166 country code (example: "GB" for Britain) of two characters. IANA holds the registry of the sub tag to be permitted.
259. The element is not allowed in the context. *9*
It is expected that an element follows the rule of a context.
For example:
- The STYLE element must follow the following rules, when it is in a SECTION element. : A STYLE element follows flow contents.
- Element SOURCE can not be the child of an element (AUDIO/VIDEO) in this context.
260. Invalid attribute value for a PROGRESS element *9*
MAX attribute and VALUE of a PROGRESS element must follow the following rules:
- The value of a VALUE attribute must be below the value of a MAX attribute.
- The value of a VALUE attribute must be zero or less, when the MAX attribute is not specified.
261. Element can not be the lower element of 'A/BUTTON' under the specified conditions. *9*
It is expected that an element follows the rule of a context.
For example:
- The element IMG with Attribute USEMAP can not be the lower element of an A/BUTTON element.
- The element with the 'TOOLBAR' value of an attribute type can not be the lower element of an A/BUTTON elemenet.
- The interactive element VIDEO with an attribute can not be the lower element of an A/BUTTON elemenet.
262. Inadequate upper element *9*
The IMG element with an ISMAP attribute set must have an upper element with a HREF attribute.
263. Inadequate hash name reference *9*
Wrong attribute value : Referring to the hash name must start with #.
264. Inadequate attribute in a context *9*
When attribute 'SRC' is not specified, an element SCRIPT cannot have an attribute 'DEFER/ASYNC/CHARSET'.
265. Unacceptable attribute in a context *9*
A default attribute can be used only on one track element in the same audio or a video element.
266. Unacceptable attribute in a context *9*
For example:
RADIOGROUP of a COMMAND element and the CHECKED attribute must follow the following rules.:
- The COMMAND element can not hold RADIOGROUP or a CHECKED attribute, when the value of a TYPE attribute is 'COMMAND'.
- The COMMAND element can not hold a RADIOGROUP attribute, when the value of a TYPE attribute is 'CHECKBOX'.
267. Inadequate attribute value for METER element *9*
VALUE, MIN, LOW, HIGH, OPTIMUM, and MAX attribute of a METER element must follow the following rules.
- The value of a min attribute must be below the value of a value attribute.
- The value of a value attribute must be zero or more, when the min attribute is not specified.
- The value of a value attribute must be below the value of a max attribute.
- The value of a value attribute must be zero or less, when the max attribute is not specified.
- The value of a min attribute must be below the value of a max attribute.
- The value of a max attribute must be zero or more, when the min attribute is not specified.
- The value of a min attribute must be zero or less, when the max attribute is not specified.
- The value of a min attribute must be below the value of a low attribute.
- The value of a low attribute must be zero or more, when the min attribute is not specified.
- The value of a min attribute must be below the value of a high attribute.
- The value of a high attribute must be zero or more, when the min attribute is not specified.
- The value of a low attribute must be below the value of a high attribute.
- The value of a high attribute must be below the value of a max attribute.
- The value of a high attribute must be one or less, when the max attribute is not specified.
- The value of a low attribute must be below the value of a max attribute.
- The value of a low attribute must be one or less, when the max attribute is not specified.
- The value of a min attribute must be below the value of an optimum attribute.
- The value of an optimum attribute must be zero or more, when the min attribute is not specified.
- The value of an optimum attribute must be below the value of a max attribute.
- The value of an optimum attribute must be one or less, when the max attribute is not specified.
268. Valid reference is expected. *9*
It is expected that an element will have the effective reference to the field which exists from before.
For example:
The LIST attribute of an INPUT element must follow the following rules.:
- The list attribute of the input element must refer to datalist element.
The CONTEXTMENU attribute (global attribute of HTML5) must follow the following rules.:
- The CONTEXTMENU attribute must refer to MENU element.
269. Unsupported tag in this HTML version *9*
Please use a suitable element and/or CSS. In the place where tt element is used for the markup of a keyboard input, please take a kbd element into consideration. Please consider a var element for a variable. Please take a code element into consideration for a computer code. And please consider a same element for computer output. If a big element is used in order to show a heading, please take use of h1 element into consideration. If the important message is used for markup, please take a strong element into consideration.
270. FRAME, FRAMESET & NOFRAMES tags are not supported in this HTML version. *9*
In order to generate perfect page with integrated various eternal parts, please use the server side includes or use IFRAME and css.
276. NOEMBED is not supported in this HTML version. *9*
Please use OBJECT instead of EMBED when fall back is needed.
278. RB is not supported in this HTML version. *9*
It is enough to provide ruby base directly in RUBY element. RB element is unnecessary, so please delete it completely.
279. STRIKE is not supported in this HTML version. *9*
Please use DEL when the element creates the postscript, otherwise please use S.
280. XMP is not supported in this HTML version. *9*
Please use CODE and escape < and & characters as < and &
281. ISINDEX is not supported in this HTML version. *9*
Please use a text area combination with explicit form.
283. CHARSET attribute in A/LINK tag is not supported by HTML5. *9*
Please use a HTTP context type header on the linked resource.
284. COORDS/SHAPE attribute in A tag is not supported by HTML5. *9*
Please use AREA instead of A for an image map.
286. NAME attribute in A/EMBED/IMG/OPTION tag is not supported by HTML5. *9*
Please use ID attribute.
287. REV attribute in A/LINK tag is not supported by HTML5. *9*
Please use a REL attribute in an opposite meaning. （E.g.: use rel="author" instead of rev="made")
288. URN attribute in A/LINK tag is not supported by HTML5. *9*
Please use a HREF attribute and specify the recommend edpermanent identifier.
289. ACCEPT attribute in FORM tag is not supported by HTML5. *9*
Please use an ACCEPT attribute directly on an input element.
290. NOHREF attribute in AREA tag is not supported by HTML5. *9*
It is enough to delete HREF attribute. NOHREF attribute is unnecessary, so please delete it completely.
291. PROFILE attribute in HEAD tag is not supported by HTML5. *9*
When used for declaration, it is unnecessary which META item is used in a document. Please delete completely and register a name. Please use a LINK element in order to start the behavior of a specific user agent.
292. VERSION attribute in HTML tag is not supported by HTML5. *9*
Please delete it completely as it is unnecessary.
293. USEMAP attribute in INPUT tag is not supported by HTML5. *9*
Please use IMG instead of INPUT for an image map.
294. LONGDESC attribute in IFRAME/IMG tag is not supported by HTML5. *9*
Please use regular A element to link to to description. Or (in case of an image) please use an image map in order to provide the link to the description of an image from the image.
295. LOWSRC attribute in IMG tag is not supported by HTML5. *9*
Please use a progressive JPEG (given in SRC attribute) image instead of using two separate images.
296. TARGET attribute in LINK tag is not supported by HTML5. *9*
Please delete it completely as it is unnecessary.
297. SCHEME attribute in META tag is not supported by HTML5. *9*
Please use only the schema of a field unit. Or please create the schema declaration part of the value.
298. ARCHIVE/CLASSID/CODE/CODEBASE/CODETYPE attribute in OBJECT tag is not supported by HTML5. *9*
In order to call plug-in, please use DATA and a TYPE attribute. A PARAM element can be used in order to set a parameter especially by these names.
299. DECLARE attribute in OBJECT tag is not supported by HTML5. *9*
Whenever a resource is reused, please repeat an OBJECT element completely.
300. STANDBY attribute in OBJECT tag is not supported by HTML5. *9*
Please optimize the linked resource in order to load quickly or at least additionally.
301. TYPE/VALUETYPE attribute in PARAM tag is not supported by HTML5. *9*
Please use NAME and a VALUE attribute, without declaring a value type.
303. EVENT/FOR attribute in SCRIPT tag is not supported by HTML5. *9*
Please use a DOM event, in order to register event listeners. [DOMEVENTS]
304. DATAPAGESIZE attribute in TABLE tag is not supported by HTML5. *9*
Please delete it completely as it is unnecessary.
305. SUMMARY attribute in TABLE tag is not supported by HTML5. *9*
Please use the alternative measure for HTML5.
306. ABBR attribute in TD/TH tag is not supported by HTML5. *9*
Please use the text which starts clearly and briefly, and include the complicated text after that. In the point of containing a more complicated text, a TITLE attribute is useful, and can make the contents of a cell brief.
307. AXIS attribute inTD/TH tag is not supported by HTML5. *9*
Please use a SCOPE attribute on a related TH.
308. DATASRC/DATAFLD/DATAFORMATAS attribute is not supported by HTML5. *9*
Please use a mechanism like XML Http Request which adds a script and a page dynamically.
