link text inside link text should be allowed. It isn’t valid html though. CommonMark shouldn’t be influenced by HTML standards. If the intended target is HTML though, then the person writing the markup will have to keep that in mind.
Hello everyone. I got kinda interested in this project.
Not only aren’t anchors not allowed in browsers. the browsers also won’t render them correctly. (They push the inner link out of the outer link)
But html is made to work even while its badly formatted
Thinking about it some more, I’d not go against HTML spec – I personally have never needed to use nested links in title, so can’t say what’s would be a common use case, but I’d say the implicit-closing-of-anchors is far more UX-unfriendly than disallowing nested links to begin with.
[the [aquila](url) rift](url2)
will IMO leave user more confused with the output due to the prematurely closed link, than if we just disallowed the nested link altogether, which will make it obvious what’s happening from first sight.
It’ll also teach users early on how to properly write links.
This argument obviously stands on the fact that markdown is mainly used for HTML output, where nested links don’t make sense. Is there even an output format where it makes sense to have nested links?
If this was a new language, option (4) would make a lot of sense. The inner link could be rendered as it is written, with literal brackets being included in the output and made safe by the parser.
Most existing parsers behave closer to (2) though. CommonMark’s goal is to be highly compatible, rather than to support the best possible syntax. Other changes have been made where the chances of breaking existing documents have been low, however.
I didn’t bring this up because I want to use links inside of links. I don’t!
I think this is a strange thing to do and I don’t expect anyone to actually do this.
My point is that the current rules are inconsistent and we should make them consistent. Once they are consistent, it would also be nice if they were really simple. And just allowing arbitrary inline nodes in link descriptions is the simplest I can think of.
Now the question is what should happen if people against all odds actually use links inside of links?
Should a CommonMark parser also be an HTML validator?
Even if the spec would disallow links inside of links, a user could still write plain old HTML that’s not conformant.
I see no point in enforcing conformant HTML, but if it is desired, it should be done in the HTML renderer.
We wouldn’t really actively “support” it, it would just happen to be possible.
If the reason for disallowing it is the HTML spec, then we would, for consistency, also have to check all HTML blocks and HTML tags for HTML conformance.
And I doubt very much that this is the goal of CommonMark.
Yes, the renderer seems to be the right place to handle this.
Since AFAIU the spec doesn’t specify the renderer, we should keep such examples out of the automated tests.
Well that’s HTMLs behavior.
I wouldn’t call that good Markdown input and blame the one who wrote it.
I think in this situation there is no “good” behavior. And in absence of “good” behavior we should strive for “consistent” and “easily understandable” behavior.
I think the CommonMark spec shouldn’t be viewed as a teaching tool.
A given implementation may want to go that way, but complicating the spec because of that is IMHO not a good idea.
No idea, but let’s just not forbid it anyway.
We are not actually adding any complexity to the spec with that, we’re removing complexity!
I think rules should be simple, but for the end user. And I think the rule should create the least amount of surprise from all the alternatives.
Besides, the consistency goes out of the window anyway coz we e.g. already disallow links (or any inline rules) in image titles (alt text). Images are also a good examle of tight coupling to HTML (since support for alt and title, both of which are HTML-specific things).
As noted above, I think markdown is tightly coupled to HTML to begin with, and by trying to reverse that we’d end up with something that might look good on paper, but any commonmark implem would be pretty much useless in a web app without extensive work on top of the spec.
I mean, if we try to decouple commonmark from HTML, every implementation would have to come up with its own rules to enforce valid HTML output from the source markup. That would pretty much defeat the purpose of the commonmark – that is a standard for markdown→output
I don’t think that’s relevant, because we’re discussing markdown spec. HTML, even if allowed to be nested within markdown documents, is a separate issue.
Nested links are allowed in embedded image syntax for a reason. Though I’m not actually sure what this reason is, I assume it is figures, i.e. when the link text is not (primarily) used for the alt accessibility attribute, but for a visible caption or legend. Mediawiki, which Wikipedia ist running on, also allows links within image references for this reason: [[Image:file_name.png|thumb|Caption with link to [[Article]].]]
Markdown parsers should turn an image reference into a figure in (HTML) output if it is the only content of a paragraph, but this is discussed elsewhere, as are other media resources like audio and video.
You might think that normal, non-embedded, non-image links are not used as (floating) figures. That is wrong. Many blogging, CMS, forum and other social media software (including Discourse) turns URLs that stand alone in a paragraph or are found at the end of a message into a “card” that usually contains title, image and content previews that are automatically fetched. In a Markdown-based environment, these cards may also use the link text provided by the author, which is not available for plain URLs, as a caption which could absolutely contain markup including links.
This alone may be reason enough to allow nested links, although they should be flattened in many common scenarios.