Opened 13 years ago
Last modified 12 years ago
#8561 confirmed Bug
Unexpected lists get created when selecting nested divs
Reported by: | Damian | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | Core : Lists | Version: | |
Keywords: | IBM | Cc: | Teresa Monahan, satya_minnekanti@… |
Description
- Start with the following content:
<div>Line 1</div> <div>Line 2</div>
- In WYSIWYG, select both lines:
<div>^Line 1</div> <div>Line 2^</div>
- Copy using ctrl+c and paste (ctrl+v) at the end of Line 1:
<div>Line 1^</div> <div>Line 2</div>
- The result is something like:
<div> Line 1<br /> <div> Line 1</div> <div> Line 2</div> </div> <div> Line 2</div>
- Select all four lines and create a list.
Result: multiple lists are created from the selection
Expected: a single list is created with all four lines
Note: The expected behavior is derived from two things. The first is that the content appears to be flat from the user's point of view and selecting it should result in a flat list. And secondly, when a similar test case is attempted using the native browser execCommand('InsertOrderedList') call, the list that is created is a single list with four items.
Attachments (1)
Change History (9)
comment:1 Changed 13 years ago by
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:2 Changed 13 years ago by
Cc: | satya_minnekanti@… added |
---|
comment:3 Changed 13 years ago by
Resolution: | duplicate |
---|---|
Status: | closed → reopened |
comment:4 Changed 13 years ago by
Status: | reopened → new |
---|
comment:5 follow-up: 6 Changed 13 years ago by
Status: | new → pending |
---|
I think part of this ticket is related to #6847. If #6847 was implemented user could E.g. press double arrow, get out of div2 and paste those two divs below and ten create single level list.
Currently, for the above TC, it is not possible to get out of div thus nested divs get created.
About lists:
The first is that the content appears to be flat from the user's point of view and selecting it should result in a flat list.
From inexperienced user point of view the whole page is flat - nothing is nested, there is no hierarchy, everything is placed where it was rendered (E.g. no position) etc.
User may think many things that does not mean it is correct.
And secondly, when a similar test case is attempted using the native browser execCommand('InsertOrderedList') call, the list that is created is a single list with four items.
Using document.execCommand('InsertOrderedList');
on divs presented above creates flat list in deed. But it will create flat list from any number of nested divs.
Furthermore check out the sample file provided. Open it in E.g. Chrome and execute the command document.execCommand('InsertOrderedList');
.
Result is that flat list gets created although from the user point if view it is not flat (I have taken your approach here)
@damo is this really what you want to have. IMO this is unnecessary complicating something that is working as it should. Waiting for your comments.
Changed 13 years ago by
Attachment: | template_test1.html added |
---|
comment:6 Changed 13 years ago by
Replying to j.swiderski:
I think part of this ticket is related to #6847. If #6847 was implemented user could E.g. press double arrow, get out of div2 and paste those two divs below and ten create single level list.
Currently, for the above TC, it is not possible to get out of div thus nested divs get created.
Although being able to leave the boundaries of the div might have helped a user who understands the problems here, it isn't really the issue being discussed in this ticket. The example steps provided are not the only way to generate the nested structure. The problem being discussed here is what happens during list creation when a nested div structure like this, is selected.
About lists:
The first is that the content appears to be flat from the user's point of view and selecting it should result in a flat list.
From inexperienced user point of view the whole page is flat - nothing is nested, there is no hierarchy, everything is placed where it was rendered (E.g. no position) etc.
User may think many things that does not mean it is correct.
What we're really talking about here is 'reasonable' user expectations. This ticket originated from the editor being used in DIV enter mode, although, this isn't necessary to reproduce these issues. In the above example, the list structure is easy enough to fix. Here is a more interesting sample that I was able to create within WYSIWYG mode, start with this:
<div>line 1</div> <div> line 2<br /> <div> line 3</div> line 4</div> <div>line 5</div>
The above results in the following list structures:
<div> <ol> <li> line 2</li> <li> line 3</li> <li> line 4</li> </ol> </div> <ol> <li> line 1</li> <li> line 5</li> </ol>
Notice that the order of the content has changed significantly. Would you agree that the result is not likely to be expected by most users, especially when working within WYSIWYG mode?
@damo is this really what you want to have. IMO this is unnecessary complicating something that is working as it should. Waiting for your comments.
This is a valid point. My answer would be no, we don't want to lose all of the indented content. We already have logic in the editor that preserves indented paragraphs and is able to go from list to paragraph and back again, preserving indentation. Your example does raise an important issue that would need to be resolved. Since the editor has a concept of indentation, there may be a way to leverage this to address the problem your example exposes.
comment:7 Changed 13 years ago by
Just to sum up (Tell me if I understand this correctly):
You would like nested divs to be changed in flattened lists with one exception to this rule - when nested divs have indentation (E.g. margins or paddings) divs should be changed to nested lists. Is that correct?
comment:8 Changed 12 years ago by
Component: | General → Core : Lists |
---|---|
Status: | pending → confirmed |
This is because CKEditor doesn't allow cursor to exit from container blocks like div, blockquote as it does with tables.
This ticket has been covered in #6847. I'm closing this one as duplicate.