On Mon, Jul 13, 2009 at 4:01 AM, Simon Pieters <sim...@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.sut...@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
