ckeditor
Empty paragraphs add to a list after importing from Word / list style none / skip-level lists
📝 Provide detailed reproduction steps (if any)
- Go to https://ckeditor.com/import-from-word/demo/#extended-import
- Import the following document: list-import-issue.docx
✔️ Expected result
There are no additional paragraphs added to the list.
❌ Actual result
New paragraphs are added to the list.
📃 Other details
- List markup from the converter: https://gist.github.com/Mgsy/ddb8412e9a06c866a12b6573dd723c4e
If you'd like to see this fixed sooner, add a 👍 reaction to this post.
- List markup from the converter: https://gist.github.com/Mgsy/ddb8412e9a06c866a12b6573dd723c4e
This markup doesn't seem to be correct. I think it's an issue on the IFW side.
OK, @jacekbogdanski helped me understand that this is more complex. I think I can see here 2 issues to address (and 3rd a bonus one):
1. The empty paragraphs
This is IMO an issue (or opportunity :D) to be handled in IFW. If every list item is separated by those paragraphs, CKE5 won't be able to fix that. CKE5 must avoid changing the input structure whenever possible (though, this is blurry).
2. Lack of support for skip-level lists (and hence list-style-type: none on those empty <li>)
I guess there's a ticket for this already but we'd need support for those: ol>ol>ol>li lists. I'd prefer if those didn't exist, but apparently they do and we can't handle this in a different way.
Note: Adding support for such lists also requires taking care of removing bullets on those skipped levels (li{list-style-type:none}). This is something different than support for list-style-type:none on <ul/ol>. The latter should be controllable by the user via the UI. The former, should be an effect of deeper indentation.
Note2: Probably the support for skip-level lists needs to be configurable. To be consistent with many other scenarios, we would need to make it opt-in. However, then we force people (and us) integrating CKE5 for a "document editor" use case to turn on all those options. Meaning – their editor configs are huge. I start to think we need a preset for this :(
3. Lack of support for list-style-type: none on <ul/ol>
Bonus point. Not related to this particular issue, but to a sibling: IFW-Issue #11.
While I'd prefer if 2nd+ blocks of a list item were correctly placed in one <li>, from what I understand, this might not be possible for IFW to implement a heuristic that would fix such broken MSWord lists. (Do I understand this correctly, @jacekbogdanski?)
If that's true, then let's at least focus on the visual aspect – getting rid of those unnecessary markers. Hence, we need to preserve list-style-type: none.
Initially, we thought that GHS could do that. But I think this is a wrong direction. If GHS would preserve such a style, then ListProperties might have a harder time managing it.
I think a much safer and sane way is to add the implicit "None" style to List properties options.
As for the No 1:
I think that in most cases, these paragraphs are created outside of list numbering. Looking at the documents we have from our customers, the paragraph between lists (so the empty in the example HTML you shared) is also visible in the Word document and detected as a paragraph. So, we are in the same spot as CKEditor 5 - we are getting XML formatted to have a paragraph between lists and converting that to corresponding HTML. We would have to develop a heuristic that would have to predict in which situations that paragraph was supposed to be a part of a list itself, which is quite hard to come up with.
What we do differently for these paragraphs, is that they have set margins top and bottom to 0 (because they have that formatting in Word), which can cause the differences in what you can see when importing that document to CKEditor 5 vs plain HTML page. Top/bottom margins are removed by CKEditor 5 without GHS.
Side note on No 1.: we will try to develop some heuristic for pasting as our lists break, and the numbering breaks as well. I want to do a PoC when we try to merge paragraphs inside the list items but I don't have more details right now. Rel: https://github.com/ckeditor/ckeditor5/issues/11210
