MSC4313: Require HTML <ol> start Attribute support

[HarHarLinks]

Rendered

Signed-off-by: HarHarLinks 2803622+HarHarLinks@users.noreply.github.com

[turt2live]

Implementation requirements:

• Client (ideally several)

[HarHarLinks]

• I know this is already implemented in Element-Web, Fractal, FluffyChat 2.0. There are likely more. What do you need as confirmation?

• Implementations meeting this proposal but with limited issues (such as not rendering the number when the item has no content) exist, e.g. Nheko 0.12.0-9571d811, NeoChat, Element/SchildiChat classic, FluffyChat 1.25.

• A counter-example would be Element X, at least on Android.

[turt2live]

arguably this is the bug, not the lack of start

[turt2live]

(also, why aren't they using polls?)

[HarHarLinks]

The spec says I may use start in my HTML body. If I use it and my conversational partner cannot interpret it correctly, then the spec does not adequately prevent communication from breaking there. How we get into this situation is irrelevant imo, unless we want to start speccing how the formatted_body must be constructed, which I hope is widely out of scope of Matrix.

(Whether to use polls or not is also not the question.)

[spaetz]

err, all that you need to do to invoke this issue is typing in EXA that you like the
4. of July.

[Johennes]

Could you prevent the sending client from turning 2. into an <ol> in the first place?

[toger5]

Independent of where this MSC goes I feel like this ("better logic for when to convert X. (numbers) into <ol>) is an issue report that should be opened against clients that currently do not do that in a sane way ?
I even remember seeing such issues iirc.

[HarHarLinks]

Should I change my example, because apparently many reviewers are missing the issue I am trying to point out for another issue.

It is currently legal and intended within the Matrix spec for Alice to type:

3. A
4. B
5. C

and Alice's client to send this as "formatted_body": "<ol start=\"3\"><li>A</li><li>B</li><li>C</li>".

The above is a legal message, and there are valid use cases to get there. This formatted_body legally existing is the basis for this MSC. It is not concerned with how to get there, as long as you are allowed to get there.

Then the issue is that Bob's client missing support for start might render it as

1. A
2. B
3. C

---

What I at this point regard as out of scope of this MSC (convince me otherwise?) is prescribing to clients how to and how not to generate their HTML. Possible ways for clients to construct formatted_bodys could be:

• interpret "plain text" as some markdown dialect (yes this is inconsistent across different clients), as most clients do today
• users enter custom HTML straight in the input box, e.g. using Element Web's /html command
• parse Org mode
• a bot doing STT and heuristically applying formatting
• any custom input language
• AI generating formatted_body from a user signing sign language into their webcam
• anything you can think of

So to get rid of erratic behavior, the spec could try to come up with rules trying to cover a million edge and corner cases that prevent a simple answer of 2. (current MSC example) or 4. of July (from spaetz) from being converted to an ol. But still the problem is not solved, see example above.

An easy alternative would be to disallow start from the spec, i.e. only allow ordered lists starting at 1, and leaving it up to clients to not mistakenly convert numbered lists starting not at 1 (incl misinterpretations like 4. of July) to ols.

Can anyone find a reference as to when start support was added to the spec, ideally the MSC and reasoning for it?

[Johennes]

I think fixing the start issue as per this proposal definitely makes sense in any case.

I was just thinking that when I type "4. Juli", I actually wouldn't want it to become an ordered list starting at 4. Even if it's displayed similarly, semantically it's something very different from what I intended. Agree that this is a different problem though and should be solved in another proposal.

[HarHarLinks]

I was just thinking that when I type "4. Juli", I actually wouldn't want it to become an ordered list starting at 4. Even if it's displayed similarly, semantically it's something very different from what I intended. Agree that this is a different problem though and should be solved in another proposal.

To be clear, I agree that this is annoying and suboptimal, and clients should do better. I am not sure though if this even falls into the area of concern of the spec.

[HarHarLinks]

For evidence, this is the case in Element X as of 25.07.0.

Further evidence: nheko 0.12.0-9571d811 and SchildiChat ("classic") will show only whitespace here.