[GH-ISSUE #56] rule MD034 flags URL in fenced block as "bare url", unlike mdl

kerem commented

2026-03-03 01:23:17 +03:00

Owner

Originally created by @mobilemind on GitHub (Apr 14, 2017).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/56

A URL inside of a fenced code block is marked as a "bare url" by markdownlint.

However, the ruby-based mdl doesn't mark the same line as a bare url.

Please resolve this difference. Thanks.

Example:
$ cat test-fenced-url.md

# Error with URL in Fenced Code Block

    ````text
http://lms.com/pens.cgi?command=collect&pens-version=1.0.0
&package-type=scorm-pif&package-type-version=1.2&package-format=zip
&package-id=http%3A%2F%2Fwww.author.com%3A994646572378864600-1085069139609
&package-url=http%3A%2F%2Fauthor.com%2Fpackages%2F1085069139609.zip
&package-url-expiry=2005-05-20T16%3A05%3A39Z&client=Author
&receipt=http%3A%2F%2Fauthor.com%2Fpens.cgi
&alerts=http%3A%2Fauthor.com%2Fpens.cgi
    ````

The above example will "pass" review by mdl, but markdownlint will trigger a warning:

$ mdl test-fenced-url.md
$ markdownlint test-fenced-url.md
test-fenced-url.md: 3: MD034 Bare URL used

Originally created by @mobilemind on GitHub (Apr 14, 2017). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/56 A URL inside of a fenced code block is marked as a "bare url" by `markdownlint`. However, the ruby-based `mdl` doesn't mark the same line as a bare url. Please resolve this difference. Thanks. Example: `$ cat test-fenced-url.md` <pre> # Error with URL in Fenced Code Block ````text http://lms.com/pens.cgi?command=collect&pens-version=1.0.0 &package-type=scorm-pif&package-type-version=1.2&package-format=zip &package-id=http%3A%2F%2Fwww.author.com%3A994646572378864600-1085069139609 &package-url=http%3A%2F%2Fauthor.com%2Fpackages%2F1085069139609.zip &package-url-expiry=2005-05-20T16%3A05%3A39Z&client=Author &receipt=http%3A%2F%2Fauthor.com%2Fpens.cgi &alerts=http%3A%2Fauthor.com%2Fpens.cgi ```` </pre> The above example will "pass" review by `mdl`, but `markdownlint` will trigger a warning: ````bash $ mdl test-fenced-url.md $ markdownlint test-fenced-url.md test-fenced-url.md: 3: MD034 Bare URL used ````

kerem

2026-03-03 01:23:17 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-03 01:23:18 +03:00

Author

Owner

@DavidAnson commented on GitHub (Apr 14, 2017):

I think the Ruby/mdl behavior is a more sensible default, so I will change this project to match it - and add a code_blocks option to opt into the current behavior for any scenarios that desire it. Thank you!

@DavidAnson commented on GitHub (Apr 14, 2017): I think the Ruby/`mdl` behavior is a more sensible default, so I will change this project to match it - and add a `code_blocks` option to opt into the current behavior for any scenarios that desire it. Thank you!

kerem commented

2026-03-03 01:23:18 +03:00

Author

Owner

@DavidAnson commented on GitHub (May 1, 2017):

I've investigated and it turns out the Node implementation of markdownlint already implements the behavior you desire. The problem is that your sample is not what you think it is. :) A code fence may not be indented by more than three spaces and yours is indented by four. (Specification: http://spec.commonmark.org/0.27/#fenced-code-blocks) As such, the body of the fence doesn't appear as such and the bare URL isn't ignored as you're expecting. Converting the example to three-space indentation gives the desired behavior in the current implementation.

If you'd like to experiment with the underlying parser, here's your example in the markdown-it playground:
https://markdown-it.github.io/#md3=%7B%22source%22%3A%22%23%20Error%20with%20URL%20in%20Fenced%20Code%20Block%5Cn%5Cn%20%20%20%20%60%60%60%60text%5Cnhttp%3A%2F%2Flms.com%2Fpens.cgi%3Fcommand%3Dcollect%26pens-version%3D1.0.0%5Cn%26package-type%3Dscorm-pif%26package-type-version%3D1.2%26package-format%3Dzip%5Cn%26package-id%3Dhttp%253A%252F%252Fwww.author.com%253A994646572378864600-1085069139609%5Cn%26package-url%3Dhttp%253A%252F%252Fauthor.com%252Fpackages%252F1085069139609.zip%5Cn%26package-url-expiry%3D2005-05-20T16%253A05%253A39Z%26client%3DAuthor%5Cn%26receipt%3Dhttp%253A%252F%252Fauthor.com%252Fpens.cgi%5Cn%26alerts%3Dhttp%253A%252Fauthor.com%252Fpens.cgi%5Cn%20%20%20%20%60%60%60%60%22%2C%22defaults%22%3A%7B%22html%22%3Afalse%2C%22xhtmlOut%22%3Afalse%2C%22breaks%22%3Afalse%2C%22langPrefix%22%3A%22language-%22%2C%22linkify%22%3Atrue%2C%22typographer%22%3Atrue%2C%22_highlight%22%3Atrue%2C%22_strict%22%3Afalse%2C%22_view%22%3A%22html%22%7D%7D

@DavidAnson commented on GitHub (May 1, 2017): I've investigated and it turns out the Node implementation of `markdownlint` already implements the behavior you desire. The problem is that your sample is not what you think it is. :) A code fence may not be indented by more than three spaces and yours is indented by four. (Specification: http://spec.commonmark.org/0.27/#fenced-code-blocks) As such, the body of the fence doesn't appear as such and the bare URL isn't ignored as you're expecting. Converting the example to three-space indentation gives the desired behavior in the current implementation. If you'd like to experiment with the underlying parser, here's your example in the `markdown-it` playground: https://markdown-it.github.io/#md3=%7B%22source%22%3A%22%23%20Error%20with%20URL%20in%20Fenced%20Code%20Block%5Cn%5Cn%20%20%20%20%60%60%60%60text%5Cnhttp%3A%2F%2Flms.com%2Fpens.cgi%3Fcommand%3Dcollect%26pens-version%3D1.0.0%5Cn%26package-type%3Dscorm-pif%26package-type-version%3D1.2%26package-format%3Dzip%5Cn%26package-id%3Dhttp%253A%252F%252Fwww.author.com%253A994646572378864600-1085069139609%5Cn%26package-url%3Dhttp%253A%252F%252Fauthor.com%252Fpackages%252F1085069139609.zip%5Cn%26package-url-expiry%3D2005-05-20T16%253A05%253A39Z%26client%3DAuthor%5Cn%26receipt%3Dhttp%253A%252F%252Fauthor.com%252Fpens.cgi%5Cn%26alerts%3Dhttp%253A%252Fauthor.com%252Fpens.cgi%5Cn%20%20%20%20%60%60%60%60%22%2C%22defaults%22%3A%7B%22html%22%3Afalse%2C%22xhtmlOut%22%3Afalse%2C%22breaks%22%3Afalse%2C%22langPrefix%22%3A%22language-%22%2C%22linkify%22%3Atrue%2C%22typographer%22%3Atrue%2C%22_highlight%22%3Atrue%2C%22_strict%22%3Afalse%2C%22_view%22%3A%22html%22%7D%7D

kerem commented

2026-03-03 01:23:19 +03:00

Author

Owner

@mobilemind commented on GitHub (May 1, 2017):

Hmm, the spec and examples seem to conflict, or at best confuse, regarding the maximum of 3 spaces.

See example #102, just below this anchor http://spec.commonmark.org/0.27/#example-101

I'll try to quote it here:

Four spaces indentation produces an indented code block:
Example 102. Try It
aaa
```
aaa
```

@mobilemind commented on GitHub (May 1, 2017): Hmm, the spec and examples seem to conflict, or at best confuse, regarding the maximum of 3 spaces. See example #102, just below this anchor <http://spec.commonmark.org/0.27/#example-101> I'll try to quote it here: >Four spaces indentation produces an indented code block: >Example 102. Try It > > ``` > aaa > ``` > ><pre><code>``` >aaa >``` ></code></pre>

kerem commented

2026-03-03 01:23:19 +03:00

Author

Owner

@DavidAnson commented on GitHub (May 1, 2017):

It IS confusing. :| But I think it's consistent.

The output in the specification INCLUDES the backtick characters - in other words, 4-space indentation is how you can show a complete code block that includes backtick characters. Here's the sample as rendered by markdown-it:
https://markdown-it.github.io/#md3=%7B%22source%22%3A%22%20%20%20%20%60%60%60%5Cn%20%20%20%20aaa%5Cn%20%20%20%20%60%60%60%22%2C%22defaults%22%3A%7B%22html%22%3Afalse%2C%22xhtmlOut%22%3Afalse%2C%22breaks%22%3Afalse%2C%22langPrefix%22%3A%22language-%22%2C%22linkify%22%3Atrue%2C%22typographer%22%3Atrue%2C%22_highlight%22%3Atrue%2C%22_strict%22%3Afalse%2C%22_view%22%3A%22html%22%7D%7D

Where yours differs is the LACK of indentation on the content between - and if you modify the sample above, it turns into the mixed output that your original output produced.

Do you agree?

@DavidAnson commented on GitHub (May 1, 2017): It IS confusing. :| But I think it's consistent. The output in the specification INCLUDES the backtick characters - in other words, 4-space indentation is how you can show a complete `code` block that includes backtick characters. Here's the sample as rendered by `markdown-it`: https://markdown-it.github.io/#md3=%7B%22source%22%3A%22%20%20%20%20%60%60%60%5Cn%20%20%20%20aaa%5Cn%20%20%20%20%60%60%60%22%2C%22defaults%22%3A%7B%22html%22%3Afalse%2C%22xhtmlOut%22%3Afalse%2C%22breaks%22%3Afalse%2C%22langPrefix%22%3A%22language-%22%2C%22linkify%22%3Atrue%2C%22typographer%22%3Atrue%2C%22_highlight%22%3Atrue%2C%22_strict%22%3Afalse%2C%22_view%22%3A%22html%22%7D%7D Where yours differs is the LACK of indentation on the content between - and if you modify the sample above, it turns into the mixed output that your original output produced. Do you agree?

kerem commented

2026-03-03 01:23:19 +03:00

Author

Owner

@mobilemind commented on GitHub (May 1, 2017):

I did more digging and made an example where mdl and markdownlint differ (with 3 space indents, and 3 ticks for the fence). However, it is clearly an edge case involving both a list and a code fence.

Basically, a code fenced that is indented exactly 3 spaces is an issue if it is underneath a list item. Both markdown-it and markdownlint show the issue. It could be my error, a CommonMark spec issue, a general parser issue, a markdown-it issue or a combination of the above.

You might want to look at the example below.

Then again, you might just want to consider the original issue closed. :-)

Permalink to a sample case with links to CommonMark Spec.

https://markdown-it.github.io/#md3=%7B%22source%22%3A%22%23%20Code%20Fence%20List%20Issue%5Cn%5CnThe%20%5C%22CommonMark%5C%22%20spec%20indicates%20that%20%28emphasis%20added%29%3A%5Cn%5Cn%3EA%20code%20fence%20is%20a%20sequence%20of%20at%20least%20three%20consecutive%20backtick%20characters%5Cn%3E%28%60%29%20or%20tildes%20%28~%29.%20%28Tildes%20and%20backticks%20cannot%20be%20mixed.%29%20%2A%2AA%20fenced%20code%5Cn%3Eblock%20begins%20with%20a%20code%20fence%2C%20indented%20_no%20more%20than%20three%20spaces_.%2A%2A%5Cn%5CnSee%3A%20%20%3Chttp%3A%2F%2Fspec.commonmark.org%2F0.27%2F%23fenced-code-blocks%3E%5Cn%5CnHowever%2C%20it%20seems%20that%20_if%20preceded%20by%20a%20list%20item_%2C%20%20an%20indent%20of%5Cn%2A%2A_exactly_%2A%2A%20_three%20spaces_%20%2A%2A_FAILS_%2A%2A%20to%20render%20with%20%60markdown-it%60.%5CnThough%20such%20cases%20%28i.e.%20this%20source%20text%29%20pass%20the%20%60mdl%60%20%28ruby%29%20lint%5Cnprocessor%2C%20they%20trigger%20cascading%20warnings%20from%20%60markdownlint%60%20%28node%29.%5Cn%5CnYet%2C%20exactly%20three%20spaces%20%2A%2Ais%2A%2A%20%5C%22_no%20more%20than%20three%20spaces_%5C%22%3B%20it%20is%20equal%5Cnto%20three%20spaces.%5Cn%5CnPerhaps%20the%20spec%20should%20be%20adjust%20to%20say%20_less_%20than%20three%2C%20or%20parsers%20and%5Cnlint%20processors%20should%20be%20adjusted.%20Or%20there%20should%20be%20caveats%20regarding%5Cnparent%20blocks%20such%20as%20lists.%20Examples%20follow.%5Cn%5Cn1.%20One%20space%20before%20code%20fence%20begin%2Fend%20markers%5Cn%5Cn%20%60%60%60Text%5Cnhttp%3A%2F%2Fauthor.com%2Fpens.cgi%3Fcommand%3Dreceipt%26pens-version%3D1.0.0%5Cn%26package-type%3Dscorm-pif%26package-type-version%3D1.2%5Cn%20%60%60%60%5Cn%5Cn2.%20Two%20spaces%20before%20code%20fence%20begin%2Fend%20markers%5Cn%5Cn%20%20%60%60%60Text%5Cnhttp%3A%2F%2Fauthor.com%2Fpens.cgi%3Fcommand%3Dreceipt%26pens-version%3D1.0.0%5Cn%26package-type%3Dscorm-pif%26package-type-version%3D1.2%5Cn%20%20%60%60%60%5Cn%5Cn3.%20Three%20spaces%20before%20code%20fence%20begin%2Fend%20markers%20%28no%20list%20item%29.%5Cn%5Cn%20%20%20%60%60%60Text%5Cnhttp%3A%2F%2Fauthor.com%2Fpens.cgi%3Fcommand%3Dreceipt%26pens-version%3D1.0.0%5Cn%26package-type%3Dscorm-pif%26package-type-version%3D1.2%5Cn%20%20%20%60%60%60%5Cn%5CnNotice%20the%20%5C%22empty%5C%22%20fenced%20code%20block%20above%20is%20is%20indented%20three%5Cnspaces.%5CnHowever%2C%20it%20might%20not%20%5C%22close%5C%22%20and%20therefore%20this%20text%20may%20appear%5Cnas%20if%20it%20were%20within%20a%20fenced%20code%20block.%5Cn%5CnAlso%20note%20that%20if%20both%20the%20opening%20and%20closing%20fence%20are%5Cnindented%20by%20four%20%28or%20more%29%20spaces%2C%20then%2C%20although%20the%20code%5Cnblock%20does%20NOT%20_render_%20properly%2C%20it%20does%20seem%20to%20%5C%22close%5C%22.%5Cn_However_%2C%20the%20spec%20indicates%20that%20a%20code%20fence%20should%20be%5Cn%5C%22indented%20no%20more%20than%20three%20spaces.%5C%22%5Cn%22%2C%22defaults%22%3A%7B%22html%22%3Afalse%2C%22xhtmlOut%22%3Afalse%2C%22breaks%22%3Afalse%2C%22langPrefix%22%3A%22%22%2C%22linkify%22%3Atrue%2C%22typographer%22%3Atrue%2C%22_highlight%22%3Atrue%2C%22_strict%22%3Afalse%2C%22_view%22%3A%22html%22%7D%7D

@mobilemind commented on GitHub (May 1, 2017): I did more digging and made an example where `mdl` and `markdownlint` differ (with *3* space indents, and 3 ticks for the fence). However, it is **clearly** an edge case involving both a list and a code fence. Basically, a code fenced that is indented _exactly_ 3 spaces is an issue _if_ it is underneath a list item. Both `markdown-it` and `markdownlint` show the issue. It could be **my error**, a CommonMark spec issue, a general parser issue, a markdown-it issue or a combination of the above. You might want to look at the example below. **Then again, you might just want to consider the original issue closed.** :-) Permalink to a sample case with links to CommonMark Spec. <https://markdown-it.github.io/#md3=%7B%22source%22%3A%22%23%20Code%20Fence%20List%20Issue%5Cn%5CnThe%20%5C%22CommonMark%5C%22%20spec%20indicates%20that%20%28emphasis%20added%29%3A%5Cn%5Cn%3EA%20code%20fence%20is%20a%20sequence%20of%20at%20least%20three%20consecutive%20backtick%20characters%5Cn%3E%28%60%29%20or%20tildes%20%28~%29.%20%28Tildes%20and%20backticks%20cannot%20be%20mixed.%29%20%2A%2AA%20fenced%20code%5Cn%3Eblock%20begins%20with%20a%20code%20fence%2C%20indented%20_no%20more%20than%20three%20spaces_.%2A%2A%5Cn%5CnSee%3A%20%20%3Chttp%3A%2F%2Fspec.commonmark.org%2F0.27%2F%23fenced-code-blocks%3E%5Cn%5CnHowever%2C%20it%20seems%20that%20_if%20preceded%20by%20a%20list%20item_%2C%20%20an%20indent%20of%5Cn%2A%2A_exactly_%2A%2A%20_three%20spaces_%20%2A%2A_FAILS_%2A%2A%20to%20render%20with%20%60markdown-it%60.%5CnThough%20such%20cases%20%28i.e.%20this%20source%20text%29%20pass%20the%20%60mdl%60%20%28ruby%29%20lint%5Cnprocessor%2C%20they%20trigger%20cascading%20warnings%20from%20%60markdownlint%60%20%28node%29.%5Cn%5CnYet%2C%20exactly%20three%20spaces%20%2A%2Ais%2A%2A%20%5C%22_no%20more%20than%20three%20spaces_%5C%22%3B%20it%20is%20equal%5Cnto%20three%20spaces.%5Cn%5CnPerhaps%20the%20spec%20should%20be%20adjust%20to%20say%20_less_%20than%20three%2C%20or%20parsers%20and%5Cnlint%20processors%20should%20be%20adjusted.%20Or%20there%20should%20be%20caveats%20regarding%5Cnparent%20blocks%20such%20as%20lists.%20Examples%20follow.%5Cn%5Cn1.%20One%20space%20before%20code%20fence%20begin%2Fend%20markers%5Cn%5Cn%20%60%60%60Text%5Cnhttp%3A%2F%2Fauthor.com%2Fpens.cgi%3Fcommand%3Dreceipt%26pens-version%3D1.0.0%5Cn%26package-type%3Dscorm-pif%26package-type-version%3D1.2%5Cn%20%60%60%60%5Cn%5Cn2.%20Two%20spaces%20before%20code%20fence%20begin%2Fend%20markers%5Cn%5Cn%20%20%60%60%60Text%5Cnhttp%3A%2F%2Fauthor.com%2Fpens.cgi%3Fcommand%3Dreceipt%26pens-version%3D1.0.0%5Cn%26package-type%3Dscorm-pif%26package-type-version%3D1.2%5Cn%20%20%60%60%60%5Cn%5Cn3.%20Three%20spaces%20before%20code%20fence%20begin%2Fend%20markers%20%28no%20list%20item%29.%5Cn%5Cn%20%20%20%60%60%60Text%5Cnhttp%3A%2F%2Fauthor.com%2Fpens.cgi%3Fcommand%3Dreceipt%26pens-version%3D1.0.0%5Cn%26package-type%3Dscorm-pif%26package-type-version%3D1.2%5Cn%20%20%20%60%60%60%5Cn%5CnNotice%20the%20%5C%22empty%5C%22%20fenced%20code%20block%20above%20is%20is%20indented%20three%5Cnspaces.%5CnHowever%2C%20it%20might%20not%20%5C%22close%5C%22%20and%20therefore%20this%20text%20may%20appear%5Cnas%20if%20it%20were%20within%20a%20fenced%20code%20block.%5Cn%5CnAlso%20note%20that%20if%20both%20the%20opening%20and%20closing%20fence%20are%5Cnindented%20by%20four%20%28or%20more%29%20spaces%2C%20then%2C%20although%20the%20code%5Cnblock%20does%20NOT%20_render_%20properly%2C%20it%20does%20seem%20to%20%5C%22close%5C%22.%5Cn_However_%2C%20the%20spec%20indicates%20that%20a%20code%20fence%20should%20be%5Cn%5C%22indented%20no%20more%20than%20three%20spaces.%5C%22%5Cn%22%2C%22defaults%22%3A%7B%22html%22%3Afalse%2C%22xhtmlOut%22%3Afalse%2C%22breaks%22%3Afalse%2C%22langPrefix%22%3A%22%22%2C%22linkify%22%3Atrue%2C%22typographer%22%3Atrue%2C%22_highlight%22%3Atrue%2C%22_strict%22%3Afalse%2C%22_view%22%3A%22html%22%7D%7D>

kerem commented

2026-03-03 01:23:19 +03:00

Author

Owner

@DavidAnson commented on GitHub (May 2, 2017):

Interesting! I think your example starts to run into the rules for list items (http://spec.commonmark.org/0.27/#list-items) and indentation, most notably example 224. As you say, this behavior - correct or not - is an artifact of the underlying parser, so not something I would try to change unless it were presenting a problem in a common scenario. The basic behavior that prompted your issue turns out to be the same for both implementations of markdownlint, so I will leave this issue closed and thank you for the interesting diversion. :)

@DavidAnson commented on GitHub (May 2, 2017): Interesting! I *think* your example starts to run into the rules for list items (http://spec.commonmark.org/0.27/#list-items) and indentation, most notably example 224. As you say, this behavior - correct or not - is an artifact of the underlying parser, so not something I would try to change unless it were presenting a problem in a common scenario. The basic behavior that prompted your issue turns out to be the same for both implementations of `markdownlint`, so I will leave this issue closed and thank you for the interesting diversion. :)

kerem referenced this issue

2026-03-07 20:02:26 +03:00

[GH-ISSUE #47] MD030, Spaces after list markers isn’t enforced if 0 spaces #1887

Rows
Columns

[GH-ISSUE #56] rule MD034 flags URL in fenced block as "bare url", unlike mdl #47