Clarify title parsing of link reference definitions
dbuenzli opened this issue · 5 comments
The text for link reference definitions is a bit hard to comprehend and a bit contradictory. See the discussion here.
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 ]
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]
I don't think this is the place for rants but, well, because the BNF for markdown (or html) is:
markdown = .*