- From: Ryosuke Niwa <rniwa@google.com>
- Date: Mon, 13 Jul 2009 08:22:03 -0700
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