W3C home > Mailing lists > Public > public-html-comments@w3.org > May 2008

Allow UL/OL as direct children of UL/OL?

From: Rocky Kahn <rocky@teampatent.com>
Date: Fri, 23 May 2008 18:44:49 -0700
Message-ID: <5e7dca810805231844w27c525f3i398247407b857953@mail.gmail.com>
To: public-html-comments@w3.org
The HTML 5 draft and preceding w3c
standards<http://www.w3.org/html/wg/html5/#the-ol>seem to specify that
<ul>/<ol> can not be direct child of <ul>/<ol>.
Specifically, the content model of <ol> and <ul> is "Zero or more
li<http://www.w3.org/html/wg/html5/#li>elements."  This poses a
problem for designing a rich text editor (which
we're doing).  Typically, when users add a list item onto an already created
list, it is encoded as a separate list rather than joining it with previous
list items.  Consider a case where a user of a rich text editor such as
Google Mail or Google Documents starts with "apple" & "banana" at level 1
and "pear" at level 2 as shown below:
  * apple
    * pear
  * banana
When the user indents "banana", it's coded as a separate <UL> as shown
below.
> <ul>
>   <li>apple</li>
>   <ul>
>     <li>pear</li>
>    </ul>
>   <ul>
>     <li>banana</li>
>   </ul>
> </ul>

Consider what happens now when the user attempts to further indent "banana"
to look like the following:
>  * apple
>     * pear
>      * banana
This could be coded correctly but that would require the editor to
automatically join pear and banana into a single <UL>.  Since "banana" was
previously coded as a separate UL, indenting it instead produces the
following code where a UL which is a direct child of a UL as shown below:
> <ul>
>   <li>apple</li>
>   <ul>
>     <li>pear</li>
>   </ul>
>   <ul>
>     <ul>
>       <li>banana</li>
>     </ul>
>   </ul>
> </ul>

This is correctly rendered on all the browsers I cared to check (FF2, IE7, &
Opera).  Is there some compelling reason to continue strictly specifying
that UL or OL may not be directly contained in a <UL>/<OL>?  If not,
considering Google's using it and all the browsers support it, perhaps the
specification ought to be changed.
Received on Sunday, 25 May 2008 19:13:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:13:58 GMT