Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify title parsing of link reference definitions #697

Open
dbuenzli opened this issue Nov 29, 2021 · 5 comments
Open

Clarify title parsing of link reference definitions #697

dbuenzli opened this issue Nov 29, 2021 · 5 comments

Comments

@dbuenzli
Copy link

The text for link reference definitions is a bit hard to comprehend and a bit contradictory. See the discussion here.

@wooorm
Copy link
Contributor

wooorm commented Nov 29, 2021

Maybe something like this is better?

A link reference definition consists of a link label, optionally preceded by up
to three spaces of indentation, followed by a colon (:), optional spaces or tabs
-(including up to one line ending), a link destination, optional spaces or tabs
-(including up to one line ending), and an optional link title, which if it is
-present must be separated from the link destination by spaces or tabs. No
+(including up to one line ending), a link destination, an optional link title,
+which if it is present must be separated from the link destination by spaces or
+tabs (including up to one line ending), and spaces and tabs. No
further character may occur.

But this one is rather hard to explain in prose as @jgm mentions without a word for [\t ]

@dbuenzli
Copy link
Author

dbuenzli commented Dec 2, 2021

But this one is rather hard to explain in prose as @jgm mentions without a word for [\t ]

This is not to take on the commonmark spec which is a very noble and useful endeavour and I respect all the hard work that went into making it happen but:

[rant]
I really don't understand why people making standards (whatwg being the ultimate offenders) are so keen on using natural language when we have accessible – in the sense you don't need higher mathematics knowledge – formalisms that make all that precise, concise and reusable across the spec.

The spec is full of repetitions of natural language constructs and hard to distinguish subtleties. For example I had example 621 failing: of course in contrast to here there's no "optional" there. With an ABNF rule for it, the distinction and actual sequencing structure would be pretty obvious.
[/rant]

@wooorm
Copy link
Contributor

wooorm commented Dec 2, 2021

I don't think this is the place for rants but, well, because the BNF for markdown (or html) is:

markdown = .*

(http://trevorjim.com/a-grammar-for-html5/)

@dbuenzli
Copy link
Author

dbuenzli commented Dec 2, 2021

@wooorm that's throwing the baby with the water :–) It's not because a BNF for the full format is useless that it is aswell for describing its components.

@jgm
Copy link
Member

jgm commented Dec 2, 2021

@dbuenzli I'm sympathetic to your rant. Perhaps it would have been better to do it that way, even though not everything will be describable in that form.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants