W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] Nested list

From: Ryosuke Niwa <rniwa@google.com>
Date: Mon, 13 Jul 2009 08:22:03 -0700
Message-ID: <5a068af50907130822h54013da3ka06d907acedbf00f@mail.gmail.com>
On Mon, Jul 13, 2009 at 4:01 AM, Simon Pieters <simonp at opera.com> wrote:
>
>
> I think this is a bug in execCommand('indent') and should be fixed in
> browsers.
>
> The spec doesn't seem to list 'indent' at all. It would be helpful if it
> was specified.
>

Yes, we need to specify how execCommand('indent' / 'insertorderedlist' /
'insertunorderedlist') works.  But given that major UAs(Firefox, Internet
Explorer, & WebKit) directly inserts ol / ul element without enclosing it
with li element, I think we should allow that construct in HTML5.

On Mon, Jul 13, 2009 at 4:07 AM, Adrian Sutton <adrian.sutton at ephox.com>
 wrote:
>
>
> It does introduce complexities when you try to indent list items more than
> one level deeper than it's parent, but semantically that really doesn't
> make
> sense anyway. You can make it work by adding a new list item but with
> list-style-type: none specified.


You still need to deal with margin / padding so you may specify them as
well.  As you said, it's very hard to make UA-generated HTML correct.  But
since major UAs produce the same DOM (ul / ol immediately inside another ul
/ ol), I don't see why we can't add that to HTML5 spec.  After all, all we
need to do is to allow li / ul / ol elements inside ul / ol instead of just
li.

Does anyone see a serious compatibility issue with adding ol / ul as child
nodes of ol / ul?  I feel like not allowing them is more problematic given
the situation.

Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090713/4ef66c0c/attachment.htm>
Received on Monday, 13 July 2009 08:22:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC