convertFromHTML is processing newlines in lists wrong
See original GitHub issueWhen having a <ol>
and in that a <li>
that has newlines in form of a <br>
in it, convertFromHTML will make every line in that <li>
it’s own list item, that appears in the surrounding list, which is not the expected result.
Example:
<ol>
<li>first</li>
<li> second<br>
with<br>
newlines</li>
</ol>
will be converted to a list with the structure:
1. first
2. second
3. with
4. newlines
Every line of the second item is a ContentBlock with type ‘ordered-list-item’
Issue Analytics
- State:
- Created 7 years ago
- Comments:10
Top Results From Across the Web
Compose output missing new lines - Power Platform Community
I am working on a flow that emails a few fields from a SP list item as a text file. The problem is,...
Read more >draft.js: how to preserve paragraph breaks when pasting ...
Pasting such text into TInyMCE, Quil, CKEditor, etc. all preserve both inline formatting and paragraphs. Pasting into draft.js removes the line breaks, so...
Read more >in2csv — csvkit 1.0.7 documentation
Description¶. Converts various tabular data formats into CSV. Converting fixed width requires that you provide a schema file with the “-s” option.
Read more >Regex assignment #2 - Digital humanities
The regex escape code that matches a new line is \n , so you want to ... consecutive new line characters), you can...
Read more >draft-js/CHANGELOG.md
20, * Preserve list indentation when copying and pasting from one Draft.js ... 143, * Fix bug where starting new line incorrectly toggled...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
#42 landed in 1.4.3
@khrykin #42 should fix that, nice catch!