Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Bug - Removing multiple list-items removes markup from other lists #4837
When removing multiple list-items by making a selection and pressing backspace or delete on the keyboard the markup is changed in other nested lists (li-items are removed) and the
List with the following markup:
After removing a selection in the first list the nested list will become:
I've tests in the 4.* and the 5.* versions of TinyMCE in Chrome, Firefox, Internet Explorer and Edge. Every version seems to be affected.
I don't know exactly how the html was created, but I noticed this issue when making some textual adjustments in it. When editing (valid) html removing a list-item at one place should never destroy other unrelated html.
Trying to create the markup in Tiny I noticed a similar/related issue. Go to the example http://fiddle.tinymce.com/uCgaab/2, place your cursor in List 1, before A and click the "Increase indent"-button. Result is that the first
Yeah you can set the content of the editor directly to be a certain way but it's nothing that can be created using the interface.
Insert text -> Insert list -> Indent creates the following html for me:
Neither Docs nor Word style the "outmost" items when you're identing more than one level. Granted, they're doing it in another way(with Docs using divs instead of actual lists/list items), but the visual result is the same.
It would be strange to have a list displayed as
What you see as Tiny destroying unrelated html is a normalization process done by the lists plugin. I shall see if there might be some changes we would want to make to this but as far as normal usage goes I think it's already close to what an end-user would expect?
I tried, and came up with a way to create the initial example using Tiny.
It is strange however when you modify another list by deleting some list-items a completely unralated list is also affected. An end user can expect that the element he/she is editing will be modified; a completely different element at the bottom of the same page doesn't seem like wanted behaviour.
This means that, yes, the example you gave now is a bug. We're going to rework the lists plugin in the near future and I shall see if we can make the normalization process capture this scenario as well!