Image with link inside - Example 459 is not very consistent

Spec
21

Sorry, I just don’t understand what point you’re making. From the point of view of the spec, ![..]() is an image with an image description, title, and destination. It’s not an “just an HTML image,” though of course it can be rendered as one.

Going back to the original example,

![foo [bar](/url)](/url2)

there are really three different defensible choices the spec could make:

  1. Allow that this is an image, and think of the [...] as a container for plain text, so that the image description is: foo [bar](/url). Renders in HTML as:
    <img src="/url2" alt="foo [bar](/url)" />.
  2. Allow that this is an image, and think of the [...] as a container for formatted inlines, so that the image description is a structured object consisting of the string foo followed by a link with link text bar and destination /url. Renders in HTML as:
    <img src="/url2" alt="foo bar" />.
  3. Forbid links in images, so that this isn’t parsed as an image at all. Renders in HTML as:
    ![foo <a href="/url">bar</a>](/url2).

I favor 2 over 1 because of the close syntactic analogy between [...]() and ![...](), and because we need to parse inline content anyway to get precedence right.

I favor 2 over 3 because there seems no good reason for disallowing image descriptions to contain links. (Surely someone who wrote example 459 would be less surprised by output 2 than output 3.)

22

I flavour (1) over (2), because argument

for me looks like attempt to define data with loss of semantic, in case of image.

Historycally, ![...] defines content as alt, that’s semantic. I can’t find a way to transform “description” (spec term) to “alt” (html term) without semantic break.

IMHO, markup should define semantic first, not data. Yes, now [...] has different semantic meaning, depending on usage. But i don’t consider it as inconsistency.

I find (3) strange, because it looks like unexpected piority break (not natural at all).

23

It’s true that Gruber’s syntax description says that the part in brackets gives the alt attribute. He was only targeting HTML. But if we have the ambition to target multiple formats, we can’t possibly explain the meaning of the part in brackets by referring to the alt attribute, which only makes sense in HTML. We need a more generic characterization of the meaning of the alt attribute. What the spec says is “image description.” That seems pretty accurate to me as a description of the abstract meaning of the alt attribute in HTML.

The HTML5 spec says that the alt attribute gives “equivalent content for those who cannot process images or who have image loading disabled.” Nothing here about whether this content can be structured or formatted. Now, of course, since HTML attributes are unstructured strings, alt attributes end up being plain unstructured text. But that, to me, seems more like an implementation detail than something about the basic semantics or meaning of the element. Nothing about the HTML5 spec’s job description for the alt attribute rules out formatting. (One can even imagine screen readers using a special voice to pronounced emphasized words, etc.)

Suppose we agree that we can’t explain the meaning as alt attribute because that’s HTML specific. Then it’s just a question of how we generalize the meaning of the alt attribute so that it could in principle apply to multiple formats. Maybe you think the proper explanation is “plain text description of the image.” I think it’s “description of the image” (plain text being an implementation detail of HTML). This is a legitimate difference of opinion. But you can’t claim that the spec isn’t defining the meaning of the [...] part.

(By the way, I agree, especially having read the HTML5 spec on alt attributes, that abusing this for image captions is probably a bad idea. That really would be a distinct meaning. As I suggested, let’s leave that issue aside.)

24

I think, you could miss the main point of alt attr in html5. It’s not evident thing. Also, people often missunderstand difference between alt and title attributes.

  • alt means alternative description (when images off). And it’s mandatory for accessibility support. Alt is alternative. Only alt OR image can be used in the same time. And it’s a plain text.
  • title means “additional information” (in html5 - on mouse hover).

Or may be it’s not sharp terms use in your post (and in spec). Every time i see word “description” (without “alternative”) applied to “alt”, kitten die :smile:

Semantically, title is more close to “image caption, hidden by default”. Title does not have markup, but at least, it’s not mutualy exclusive with image.

I have bad news. We can’t do that without semantic break. Alt should stay alt and nothing else. See explanation above. If you don’t believe - try to google “difference between alt ant title”. It’s really difficult to understand this part of html5 spec without additional articles.

May be, you meaned “can we define alternative use of […] notation”? Yes, we can. For example, we can say that it’s renderer specific (title everywhere except html), and result of different renderers can have different meaning. This choice depends on spec goals. For example, if spec does not need to care about 100% correct html semantics, it’s current approach may work.

(personally, i don’t like any of this samples, and can’t suggest “correct” generalization)

Technically, spec defines “markup to data transformation rules”. We can even say, spec is axiom and doesn’t need proofs. It’s ok, until someone ask:

  • what is operational domain of this spec?
  • can this spec be used for transformations into different formats with THE SAME meaning (not just close or similar)?

People, reading spec, have some default expectation about final result. My personal expectations are:

  • markdown markup clarification / compatibility
  • semantically-correct transforms (with html5 covered, as major case)

May be i expect to much, but i guess i’m not alone.

25

+++ Vitaly Puzrin [Jan 20 15 21:42 ]:

Yes, it’s the root of problem. If we manage to define how to handle figures, that will remove all questions like “where to place description” and “should description contain markup or not”.

Well, I think even with a separate resolution for figures, it still makes sense to store formatted inlines in the AST for the “image description,” and downshift in the renderer.

26

+++ Vitaly Puzrin [Jan 21 15 06:38 ]:

I think, you could miss the main point of alt attr in html5. It’s not evident thing. Also, people often missunderstand difference between alt and title attributes.

  • alt means alternative description (when images off). And it’s mandatory for accessibility support. Alt is alternative. Only alt OR image can be used in the same time. And it’s a plain text.
  • title means “additional information” (in html5 - on mouse hover).

Or may be it’s not sharp terms use in your post (and in spec). Every time i see word “description” (without “alternative”) applied to “alt”, kitten die :smile:

I’m aware of the distinction. I’d be happy to add the word “alternative” to “image description” in the spec. But I’d still want the AST to contain formatted inlines for the “alternative image description.”

If you think about it, lots of formats have a need for an “alternative image description.” One good example is man pages, which don’t have images. If you convert a CommonMark file to a man page, you’d want an alternative image description to be placed where the image would go, perhaps in brackets. But note: for this renderer, there would be absolutely no reason to restrict the alternative image description to plain text. Formatted text would be fine and could be useful. The restriction to plain text is an implementation detail specific to HTML.

I have bad news. We can’t do that without semantic break. Alt should stay alt and nothing else. See explanation above.

Is this resolved if I add the word “alternative” in the spec?

Technically, spec defines “markup to data transformation rules”. We can even say, spec is axiom and doesn’t need proofs. It’s ok, until someone ask:

  • what is operational domain of this spec?
  • can this spec be used for transformations into different formats with THE SAME meaning (not just close or similar)?

People, reading spec, have some default expectation about final result. My personal expectations are:

  • markdown markup clarification / compatibility
  • semantically-correct transforms (with html5 covered, as major case)

May be i expect to much, but i guess i’m not alone.

Well, we could have the spec define both an abstract representation of the document (the AST) and the recommended HTML5 rendering of each element. I think some people had suggested having both XML and HTML for each example, which would be one way of doing this.

I wouldn’t want to do that for every conceivable output format, but HTML might have a certain pride of place.

27

I don’t see principal problem to store markup if alt really needed it in some output format. The source of confusion was constant use attribute of another type as example (caption).

Though, i would check that markup in alt is really useful (while alt still stay alt and not become something else). Personally, i’m not sure, but i don’t have much experience out of html.

That will help a lot, if we both mean the same alt meaning, as described in HTML5 (+ probably with allowed markup).

Well. Now about links in images. If makrup in alt confirmed, it’s not principle for me how to render. Both stripping and leaving markup in generated html will be logical.

28

Replying to this old thread since I just ran into this – in example #422 (v0.18). The thing that surprised is that this is the first time that I’ve seen text that disappears into thin air – it’s not visible text or html markup. That, in itself, is in my opinion grounds for at least some “pay attention to this thing that happens here” comment.

But on the more meta level of what to do with it, what it does now looks fishy to me too. In my case I’m writing some elisp code to do proper highlighting of commonmark text – so I’m not concerned about how things render but in how to show them in a source editor. As it currently stands, it seems like the it should be displayed in some way that makes it look like an error. (“It” would be the text that gets eliminated – /url in the above example.) (I’m not going to do it though, since it’ll be hard to implement.)

But I also see the reason for allowing other markdown things in the text like emphasis, even when they’re not shown in an HTML rendering too. In addition, the argument about some figure extension seems shaky to me, since IMO it should be something that is different than inline links anyway. So I imagine this being useful in some kind of a popup when hovering over an image – some alt or title or whatever that can contain HTML. So all of that seems to me to be an argument for allowing links in links too, since a similar popup can apply there too.