GitHub Flavoured Markdown in Agenda field doesn't match GitHub

[nigelmegitt]

If I copy and paste agenda text in GFM from a GitHub issue into the Agenda part of a meeting, the rendering is very different to what GitHub shows, and invariably a lot worse, particularly with numbered lists.

For example see w3c/ttwg#186 and https://www.w3.org/events/meetings/cc92c9de-13de-49c8-9c08-1882127165c4/20210527T150000#agenda - the latter is after I put extra line breaks between each line; before I did that the text was presented as all one paragraph.

[jean-gui]

From what I can see https://github.com/w3c/ttwg/issues/186 does not use a numbered list. It's just rendered as a paragraph with new lines and some text in bold.

To use numbered lists you'd have to use:

1. This meeting
2. TTML2
    1. Open issues
        1. Shear calculations and origin of coordinate system. w3c/ttml2#1199 
        2. Mention fingerprinting vectors in privacy considerations. w3c/ttml2#1189 
        3. Clarify if the first ISD must/may be constructed when empty w3c/ttml2#1232
3. AOB – please notify of any other AOB now!
4. TPAC 2021

To create a new line you can either end one with two spaces or one backslash (see https://commonmark.org/help/tutorial/03-paragraphs.html). Github markdown seems to also interpret new lines as such, but this seems to conflict with the Markdown spec. This is a case where the markdown lib we use differs a bit from Github.

So if you want the same display as GitHub's you'd have to use this code:

**1. This meeting**\
**2. TTML2**\
2.1 Open issues\
2.1.1 Shear calculations and origin of coordinate system. w3c/ttml2#1199\
2.1.2 Mention fingerprinting vectors in privacy considerations. w3c/ttml2#1189\
2.1.3 Clarify if the first ISD must/may be constructed when empty w3c/ttml2#1232\
**3. AOB – please notify of any other AOB now!**\
4.1 TPAC 2021

Does that answer your concern?

[nigelmegitt]

This is a case where the markdown lib we use differs a bit from Github. ... Does that answer your concern?

No, the concern is that they don't match! Since they do not behave the same, it would make sense either not to claim that GFM is supported (and be accurate about what markdown flavours are supported), or to fix the different behaviours so that GFM is in fact supported.

As a workaround, it is useful to know about the line end trick, so thank you for that.

[jean-gui]

The spec is a little fuzzy about soft breaks and leaves the choice of how to handle them: "A renderer may also provide an option to render soft line breaks as hard line breaks."

Fortunately, I found out there's an option in the library to consider soft breaks as line breaks so now a new line, double spaces and \ should all insert a <br\/>.

Let me know if that works for you.

[nigelmegitt]

Sounds good to me, thanks @jean-gui !

[nigelmegitt]

This fixed confirmed. It looks good for the first one I've done, copying and pasting the markdown directly from the issue, which generates https://www.w3.org/events/meetings/cc92c9de-13de-49c8-9c08-1882127165c4/20210610T150000 successfully matching https://github.com/w3c/ttwg/issues/187 .