Markdown: There is a strange spacing problem when using the "list".

[YamatoRyou]

Steps to reproduce

n/a

Outcome

What did you expect?

If there are more than one list of the entire text at the same time, I hope that the correct lines can be rendered between the list. As shown in the figure:

What happened instead?

If the list is located at the top of the entire text, the line of the last line of the list and the next line is 0. As shown in the figure:

If there are other texts at the top of the list, there is a spacing of at least 1 line of text at the top of the list and the previous line. As shown in the figure:

If the entire text appears more than 1 or more list at the same time, it looks like this:

The whole looks uncomfortable, because the "list title" I expect is not together with the "list text".

---

It is also futile to press the Enter key multiple times.
Plain text:

{EFCE3F31-3D65-384C-169A-928F9C5C94F4}
- {425891E9-89A0-A717-ECF3-7C74874E248D}
- {EA6D345B-2018-85AE-96A5-4F3D5D3246C0}
- {F42E50ED-BC4D-CD22-551A-DEC529A6600F}
- {09B08711-F4B7-5E0A-D205-FCD4C18E94AC}
- {ABE49DB9-3D14-9767-9DFC-08DA31B8A9B7}
- {EF4CC90A-D0CF-0B20-34EB-20E6120CD3CF}
- {33B4F45A-638A-7EDA-CCD9-39F1F25FFCE6}
- {771C20AA-F645-F294-63C8-51FDD2B326FD}
- {BB844CFB-89FF-654D-FAB7-6909B2064F14}  




{69DEC00C-4187-722B-841C-DABCB22C1BE8}  
1. {5CA0606D-8CCA-F2C3-A571-647B93A511D3}
2. {FCBB73E0-8E94-7F38-512B-5FED7344D292}
3. {FA8B6E75-006E-2569-11B0-3EC4542F2CF8}
4. {F52A639F-E322-72CB-91BB-FB721505DEC4}
5. {6397F652-8313-251C-63F3-46B8D70AF02E}
6. {3E721DB8-C4F7-8ABF-0864-DB425B131503}
7. {B1C03E34-B203-E04A-B957-ED4B83D13494}
8. {53F454DC-FC61-1AA7-844E-F951F3FB49A0}
9. {975C802D-8F1B-8D61-1C3D-115DD34E72B7}

Result after rendering:

Operating system

x64 Windows 7

Browser information

Chromium 102.0.5005.167

URL for webapp

27f1d99-react-39fe72e53ad6-js-8a3d7d5671e5

Application version

No response

Homeserver

Synapse 1.77.0

Will you send logs?

No

[richvdh]

For the record: this appears to have been introduced by matrix-org/matrix-react-sdk#9871 (in particular, https://github.com/matrix-org/matrix-react-sdk/pull/9871/files#diff-5d3e25eb1d22dd7a96e0e87ea9c1298dc7dbce8eb965d30b2d1ebc1436bfec3fR628-R632)

[t3chguy]

This isn't the first time the WYSIWYG work has regressed the visuals of the non-labs timeline :/

[richvdh]

This isn't the first time the WYSIWYG work has regressed the visuals of the non-labs timeline :/

<shrug>. I feel like this sort of bug is inevitable if we're going to change anything in the application. Having four different display modes each with their own spacing settings doesn't help. We (or our helpful contributors) fix the bugs and move on.

It does show why we need to be careful about adding even more complexity to the CSS though.

[t3chguy]

I'm not entirely sure why the WYSIWYG editor should be touching timeline code at all? Given that implies it is changing what is sent over the wire and thus impact other clients

[richvdh]

@8227846265:

The same message but on Element Android

If you're seeing similar problems on EA, please open a separate issue over at https://github.com/vector-im/element-android.

[richvdh]

I'm not entirely sure why the WYSIWYG editor should be touching timeline code at all? Given that implies it is changing what is sent over the wire and thus impact other clients

I don't think so. In the process of developing the WYSIWYG editor we may come across things that aren't displayed correctly (in the timeline, and, since it's a WYSIWYG editor, by implication in the composer). In the process of trying to fix those things, we might introduce bugs elsewhere.

The only alternative would be to stack up a bunch of separate CSS specific to the WYSIWYG editor, but that (a) doesn't help help us fix the original problem (b) means that the WYSIWYG editor is no longer strictly WYSIWYG (c) still leaves us having to fix the introduced problem for the WYSIWYG editor.

There's certainly an argument that fixes-for-things-found-during-WYSIWYG-development should be pulled out to separate PRs to the actual WYSIWYG development - to make it clear what the original problem actually was, and to make it easier to fix any regressions that arise. But it doesn't help us avoid the regressions or having to fix them.