Re: Please look at your groups' charters rendered through markdown

[Robert Sparks <[e-mail]>]

On 9/21/21 11:49 AM, Toerless Eckert wrote:
> Nice job already, thanks a lot, Robert & team!
>
> On Mon, Sep 20, 2021 at 02:29:38PM -0500, Robert Sparks wrote:
>> And here we hit the issues with the different versions of markdown at
>> different sites.
>>
>> Github markdown treats leading space differently than Gruber's markdown.
> Can we please have an authoritative documentation of the markup used

Right now, the authoritative documentation is at the links I sent below 
(into Pypi and at daringfireball).

To save you a little digging, very relevant spots are at

https://python-markdown.github.io/#Features

and

https://daringfireball.net/projects/markdown/syntax

(and because I've turned on "extra"

https://python-markdown.github.io/extensions/extra/

>   
> and a web page that will render an input text ?

As a workaround for now, you can do this locally as documented here:

https://python-markdown.github.io/cli/

for example: (env) rjsparks@unformal markdown % python -m markdown -x 
extra src.md


>
> That way chairs can see how a version of a charter will look that
> they have fixed up with the best rendering options for their charter text.
> That should minimize work for the tools team to enhance/fixup the markup.
>
> If we need fixups, they should be in the way of wrappers to
> avoid local versioning of an actual markup, such as done with
> kramdown-rfc2629. For example to convert markup for
> well known names such as RFC* and draft-* into URLs.
>
> Cheers
>      Toerless
>
>> The relevant part of the source for the thing ending up with a different
>> rendering looks like this (via hexdump -C). Best viewed in fixed width.
>>
>> 00000100  6c 65 64 20 62 65 6c 6f  77 3a 0a 0a 20 20 20 31  |led below:..
>> 1|
>> 00000110  2e 20 54 68 65 20 66 69  72 73 74 20 61 72 65 61  |. The first
>> area|
>> 00000120  20 6f 66 20 77 6f 72 6b  20 69 73 20 6d 61 69 6e  | of work is
>> main|
>> 00000130  74 65 6e 61 6e 63 65 20  61 6e 64 20 65 76 6f 6c |tenance and
>> evol|
>> 00000140  75 74 69 6f 6e 20 6f 66  20 74 68 65 20 65 78 69 |ution of the
>> exi|
>> 00000150  73 74 69 6e 67 20 51 55  49 43 20 73 70 65 63 69 |sting QUIC
>> speci|
>> 00000160  66 69 63 61 74 69 6f 6e  73 3a 0a 0a 20 20 20 20 |fications:..
>> |
>> 00000170  20 20 20 20 20 2a 20 4d  61 69 6e 74 65 6e 61 6e |     *
>> Maintenan|
>> 00000180  63 65 20 61 6e 64 20 65  76 6f 6c 75 74 69 6f 6e  |ce and
>> evolution|
>> 00000190  20 6f 66 20 74 68 65 20  51 55 49 43 20 62 61 73  | of the QUIC
>> bas|
>> 000001a0  65 20 73 70 65 63 69 66  69 63 61 74 69 6f 6e 73  |e
>> specifications|
>>
>> That is, there are 9 spaces before what you intend to be a bullet mark.
>>
>> For what's at https://pypi.org/project/Markdown/ (implementing
>> https://daringfireball.net/projects/markdown/), anything that starts with 4
>> or more spaces or a tab is a blockquote.
>>
>> Do you easily see a single input file that gets the desired output out of
>> both renderers?
>>
>> RjS
>>
>> On 9/20/21 2:17 PM, Lars Eggert wrote:
>>> On 2021-9-20, at 20:34, Robert Sparks <[e-mail]> wrote:
>>>> Bring any issues with the markdown rendering of the current charter text to me.
>>> Not my group anymore, but QUIC looks a bit odd: https://datatracker.ietf.org/group/quic/about/rendertest/
>>>
>>> That should be an indented bullet list under 1., as shown on https://github.com/quicwg/wg-materials/blob/main/charter/charter.md
>>>
>>> Thanks,
>>> Lars
>>>