Skip to content

CommonMark spec gaps grouped by root cause, and a question about lookup tables #4050

Description

@luantaraschi

I ran the spec suite on main (18.0.9, 681373c) and went through the cases carrying shouldFail to see what is actually left. Since update-specs.js sets that flag from whatever fails at the time it runs, the set is a snapshot of current behavior rather than a list of decisions, so I grouped it by root cause. Posting it in case it is useful for triage, and because two of the groups run into the same wall and that seems worth asking about before anyone starts on them.

CommonMark 0.31.2, gfm: false, 15 cases:

Root cause Examples Count
Character references in link destination and title 32, 33, 503 3
Nested brackets in link text 512, 518, 519, 520, 528, 532, 533 7
Raw HTML and autolinks taking precedence over links 524, 526, 536, 538 4
Unicode case folding of link labels 540 1

Running the same file with gfm: true flags 4 more (602, 608, 611, 612), but those look like the autolink extension doing its job against a spec file written before it existed. For instance 611 expects https://example.com to stay plain text and marked links it, which is what GFM asks for. I would not count those as gaps.

gfm.0.29 has 4: 633, 634 and 635 are mailto: and xmpp: autolinks, 657 is the disallowed raw HTML filter.

The wall

The two smallest groups look approachable until you try them, and both need a lookup table, which sits badly with marked having no runtime dependencies.

Character references, current output on the left:

[foo](/föö "föö")
  <p><a href="/f&ouml;&ouml;" title="f&ouml;&ouml;">foo</a></p>
  <p><a href="/f%C3%B6%C3%B6" title="föö">foo</a></p>

[link](foo%20b&auml;)
  <p><a href="foo%20b&auml;">link</a></p>
  <p><a href="foo%20b%C3%A4">link</a></p>

Leaving the entity in place works for text content because the browser resolves it, but a destination has to be decoded first and then percent encoded, and getting there means the HTML5 named reference table.

Case folding is the same shape. Example 540 wants [ẞ] to match [SS], which needs full folding to ss. I tried the usual shortcuts and neither gets there:

'ẞ'.toLowerCase()                    // 'ß'
'SS'.toLowerCase()                   // 'ss'
'ẞ'.toUpperCase().toLowerCase()      // 'ß'

The question

Would you take a PR that adds a table for either of these, and if so is there a size budget worth knowing about? Or would you rather they stay as known gaps and keep the dependency-free footprint as it is?

Happy to do the work on whichever you would accept. If the answer is neither, that is a useful answer too, and it might be worth a note somewhere so the next person does not rediscover it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions