Fragment resolution

[ericonr]

Hi! We use fragment resolution quite a lot, and running linkcheck with debug made me realize it currently isn't implemented. Do you have any ongoing development on it or some ideas for how to implement it?

[Michael-F-Bryan]

I haven't really planned to implement it any time soon, but it should be fairly straightforward to do.

When checking web links we need to send a GET request, parse it as HTML (html5ever), then make sure a tag has the desired id (selectors). To keep the benefits from #1, I'd send a GET request when a fragment specifier is provided, and a HEAD request otherwise.

Validating filesystem links may be a bit more difficult... You need to figure out how to parse the document based on its file type. It also makes things interesting in that the strategy used when generating IDs for a markdown title is totally up to the renderer. You could hit a situation where linking to the # Getting Started section in ../introduction.md might get a getting-started ID from one program (e.g. mdbook), but could get a generic heading-1 ID when rendered using something else.

[l4l]

Don't it need a full JS support, to handle dynamic anchors, e.g. for SPA?

[Michael-F-Bryan]

@l4l potentially. However I'd expect the vast majority of anchors to be used for linking to relatively static sites (e.g. a page on MDN or another section of the book).

If the demand was there we could use something like fantoccini to control a browser remotely and do the linkchecking there. That adds a lot of overhead to both runtime and compile times, though.

[RumovZ]

I've implemented fragment checking for the Anki project. It's probably not good enough to be merged (see below), so I won't open a PR, but here are the repos in case anyone has use for it:
https://github.com/RumovZ/mdbook-linkcheck
https://github.com/RumovZ/linkcheck

Notable limitations:

• Local link checking only works for Markdown files with atx-style headings.
• Web link checking only works for statically available anchors.