I’ve submitted a PR that “improves” the html rendering of GFM task lists, but it fails compliance tests that are based on hardcoded HTML outputs originating in the Github Flavored Markdown Spec .
I’d like to find an owner of this spec, or otherwise get a pointer to the team currently responsible for it, to see if they’d accept alternative HTML outputs for the task list input.
For the curious, the rendering problem statement
And the PR .
We had some trouble locating the source previously. Looking at the current github
organisation on GitHub, the source appears to still be in the github/cmark-gfm repo; you could try creating an issue there.
Also of interest perhaps:
opened 07:09PM - 23 Oct 22 UTC
The published HTML version of the GFM specification at https://github.github.com… /gfm is not up to date with the `test/spec.txt` source as of https://github.com/github/cmark-gfm/blob/cedbeb7dc8005e54b8bdfe4cf442752b742be3f6/test/spec.txt.
It is at least multiple commits and years (2019) behind at this point.
There are also examples in the HTML version such as https://github.github.com/gfm/#example-493 which do not seem to have ever been part of the `spec.txt` commit history.
This is the most problematic thing, because the sequential numbers of the examples in the HTML are no longer in sync with the `spec.txt`, which is a problem when trying to programatically generate links to the canonical HTML examples.
Also, the version numbers for the spec are not being kept in sync - the [latest commit](https://github.com/github/cmark-gfm/commit/cedbeb7dc8005e54b8bdfe4cf442752b742be3f6) didn't bump the version in `spec.txt`, and the full version from some commits (e.g. https://github.com/github/cmark-gfm/commit/cedbeb7dc8005e54b8bdfe4cf442752b742be3f6) are not reflected in the spec.
If these are "prerelease" versions, and not intended to be published to the HTML version, then this versioning strategy should be clearly documented.
It's also not clear where https://github.github.com/gfm is being hosted or published from - is this a separate open source repo somewhere? If not, can it be?
In any case, it seems like this publishing process should be automated via a pipeline or GitHub Actions, to prevent it from becoming out of date, or, as is the case with https://github.github.com/gfm/#example-493, containing something that was apparently never part of `spec.txt`. And ideally this process would be open source so it is transparent and can benefit from community support.
CONTEXT: I'm finding these inconsistencies as part of GitLab's work on our own GitLab Flavored Markdown Specification, which is an extension of GitHub Flavored Markdown. See these links for more context:
- https://docs.gitlab.com/ee/user/markdown.html
- https://docs.gitlab.com/ee/development/gitlab_flavored_markdown/specification_guide
Thanks!