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

Precedence of link within link #193

Open
Knagis opened this Issue Nov 10, 2014 · 8 comments

Comments

Projects
None yet
4 participants
@Knagis
Contributor

Knagis commented Nov 10, 2014

Example 389 shows what happens when a link is nested within a link - the inner link is rendered. But I can't find the rule describing this - probably a statement similar to the emphasis rule (closed-first and opened last) should be added.

@Knagis

This comment has been minimized.

Show comment
Hide comment
@Knagis

Knagis Nov 10, 2014

Contributor

Furthermore, there is an inconsistency between how links and images are handled:

Example 389:
[foo [bar](/uri)](/uri) ➡️ <p>[foo <a href="/uri">bar</a>](/uri)</p>

Example 436:
![foo ![bar](/url)](/url2) ➡️ <p><img src="/url2" alt="foo bar" /></p>

My opinion is that there should be no difference between nested images and links in these cases.

Contributor

Knagis commented Nov 10, 2014

Furthermore, there is an inconsistency between how links and images are handled:

Example 389:
[foo [bar](/uri)](/uri) ➡️ <p>[foo <a href="/uri">bar</a>](/uri)</p>

Example 436:
![foo ![bar](/url)](/url2) ➡️ <p><img src="/url2" alt="foo bar" /></p>

My opinion is that there should be no difference between nested images and links in these cases.

@jgm jgm added the spec label Nov 17, 2014

@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Dec 26, 2014

Member

@Knagis - I don't think this is an inconsistency. There's an important difference between the two cases. Links are not allowed in the link text of a link, but they are allowed in the image description. The difference is obscured a bit by the fact that links are not rendered as links inside an alt attribute, but see the AST output:

% ./cmark -t ast
[foo [bar](/uri)](/uri)
paragraph
  text "["
  text "foo "
  link url="/uri"
    text "bar"
  text "]"
  text "(/uri)"
% ./cmark -t ast
![foo ![bar](/url)](/url2)
paragraph
  image url="/url2"
    text "foo "
    image url="/url"
      text "bar"
Member

jgm commented Dec 26, 2014

@Knagis - I don't think this is an inconsistency. There's an important difference between the two cases. Links are not allowed in the link text of a link, but they are allowed in the image description. The difference is obscured a bit by the fact that links are not rendered as links inside an alt attribute, but see the AST output:

% ./cmark -t ast
[foo [bar](/uri)](/uri)
paragraph
  text "["
  text "foo "
  link url="/uri"
    text "bar"
  text "]"
  text "(/uri)"
% ./cmark -t ast
![foo ![bar](/url)](/url2)
paragraph
  image url="/url2"
    text "foo "
    image url="/url"
      text "bar"
@Knagis

This comment has been minimized.

Show comment
Hide comment
@Knagis

Knagis Dec 26, 2014

Contributor

For me it feels that these similar looking cases should act the same in terms of which - inner or outer - link/image takes precedence (but that is just a visual thing by looking at these two cases). And for links the same approach as with images would be used - the contents of the link are parsed as is in the AST but rendered without the nested link. So the output for 389 would be <a href="/uri">foo bar</a>.

The only practical benefit though for this approach (apart from the test cases looking nicer together) is that an application could walk the AST and issue a warning that the link-within-link is not a valid construct. If the parser creates text nodes, this cannot be done.

Contributor

Knagis commented Dec 26, 2014

For me it feels that these similar looking cases should act the same in terms of which - inner or outer - link/image takes precedence (but that is just a visual thing by looking at these two cases). And for links the same approach as with images would be used - the contents of the link are parsed as is in the AST but rendered without the nested link. So the output for 389 would be <a href="/uri">foo bar</a>.

The only practical benefit though for this approach (apart from the test cases looking nicer together) is that an application could walk the AST and issue a warning that the link-within-link is not a valid construct. If the parser creates text nodes, this cannot be done.

@Knagis

This comment has been minimized.

Show comment
Hide comment
@Knagis

Knagis Dec 26, 2014

Contributor

If that lone argument did not convince you, this issue can be closed - I will then adjust my parser accordingly.

Contributor

Knagis commented Dec 26, 2014

If that lone argument did not convince you, this issue can be closed - I will then adjust my parser accordingly.

@Knagis

This comment has been minimized.

Show comment
Hide comment
@Knagis

Knagis Jan 17, 2015

Contributor

Looking at the github commits I just realized a rather good example how links within links could be used if the renderer decides to support it:

[Fixed [#285](/issues/285) in cmark](/commits/12345)

<a href="/commits/12345">Fixed </a><a href="/issues/285">#285</a><a href="/commits/12345"> in cmark</a>
Contributor

Knagis commented Jan 17, 2015

Looking at the github commits I just realized a rather good example how links within links could be used if the renderer decides to support it:

[Fixed [#285](/issues/285) in cmark](/commits/12345)

<a href="/commits/12345">Fixed </a><a href="/issues/285">#285</a><a href="/commits/12345"> in cmark</a>
@jgm

This comment has been minimized.

Show comment
Hide comment
@jgm

jgm Jun 15, 2015

Member

Commit #331 clarifies this in the spec, but I'm leaving this issue open, because I think it still needs rethinking.

Member

jgm commented Jun 15, 2015

Commit #331 clarifies this in the spec, but I'm leaving this issue open, because I think it still needs rethinking.

@mity

This comment has been minimized.

Show comment
Hide comment
@mity

mity Jun 7, 2017

Also note there is yet another inconsistency: While links cannot be nested in each other, an autolink on the other side is allowed to be nested in the link text.

See [<http://foo>](/url)

mity commented Jun 7, 2017

Also note there is yet another inconsistency: While links cannot be nested in each other, an autolink on the other side is allowed to be nested in the link text.

See [<http://foo>](/url)

@mgeier

This comment has been minimized.

Show comment
Hide comment
@mgeier
Contributor

mgeier commented Jun 7, 2017

@jgm jgm added this to the 0.29 milestone Aug 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment