This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
find below the example, which produces this (well known annoying) error with directly nested lists in the w3c HTML (4.01) validator: Line 10, Column 6: document type does not allow element "UL" here; assuming missing "LI" start-tag <ul> I know that there were already a couple of threads on this (with argument that subs must be LI's (a req for a "block" would ok for nested ul/ol's)), but I want to point to the HTML (4.01) specification which allows nested lists. See e.g.: http://www.w3.org/TR/html401/struct/lists.html#idx-list-3 (Example etc following "lists may also be nested:") (the deprecation note has not to do with nesting style but with <ol> numbering issues) Also some widely used contemporary HTML editors like Seamonkey/Mozilla and Kompozer and (my last version of) Frontpage produce directly nested lists by default from scratch, when using the list+indent GUI/buttons regularly. Also I have not seen any problems in any browser, and also CSS paths like " ul > ul", "ul ul" work correctly everywhere with directly nested lists. So I'd expect that many people have trouble with the w3c validator here - without good or just or strong reason. Also there are many examples with direct nested lists in use. The w3c validator is the only thing which makes problems with directly nested lists. There may also a be good reason to use direct nesting, because with hierachical menus etc there is often a wish to avoid extra padding/margin and other problems which come with an extra li. To avoid extra "balls" it would be necessary to have the sub-li/ul like <li>subdir<br><ul>...</ul>, which often would cause strange inheritance problems, when one really wants nested lists and not a list inside an li. both, <ul><ul><li> , and <ul><li>..<ul><li> make sense, different sense. Both should be allowed. And finally an "association": in OS file folder, there can be folders directly inside folders, Or there could be files inside a zip file in a folder. Similar, but different - both things have their use. Thus I'd vote for removal of this error message. (I'd not even say that its a warning - it is ok by specification) Example: ======= <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html><head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <title>some title</title> </head><body> ttt<br> <ul> <li>aaa</li> <li>aaa</li> <ul> <li>bbb</li> <li>bbb</li> </ul> <li>aaa<br> </li> </ul> xxx<br> </body></html>
The DTD definitely forbids lists (UL and OL) to contain anything else than LI. The nested lists example listed in the norm is: <UL> <LI> ... Level one, number one... <OL> <LI> ... Level two, number one... <LI> ... Level two, number two... <OL start="10"> <LI> ... Level three, number one... </OL> <LI> ... Level two, number three... </OL> <LI> ... Level one, number two... </UL> <http://www.w3.org/TR/html401/struct/lists.html#idx-list-3> This example is deprecated, but only because of the "start='10'". Because of indentation, it seems that the two OLs are children of an UL or OL, and thus are non DTD compliant. But in fact, LIs are implicitly closed only when the next LI at the same level starts. Hence, the first OL is inside LI level one number one, and the second OL is inside LI level two number one. Which is perfectly DTD compliant. Basically, we have a DTD that explicitly forbids directly nested lists and a spec that is somewhat obscure. In such a case I recommend following the DTD (which is normative). Thus I vote for this bug to be marked invalid.
See comment 1.