Feature: allow to provide titles for link list in html formatter

[vitalets]

🤔 What's the problem you're trying to solve?

Currently HTML formatter can show link list as raw URIs. With long URIs it can lead to cluttered ui:

✨ What's your proposed solution?

Allow this.link() to accept list of objects { title: string, url: string }:

this.link(
    { title: 'Cucumber-js', url: 'https://github.com/cucumber/cucumber-js?param=value' },
    { title: 'Cucumber-jvm', url: 'https://github.com/cucumber/cucumber-jvm?param=value' },
);

Then output in reporter would be as follows:

⛏ Have you considered any alternatives or workarounds?

No response

📚 Any additional context?

No response

[davidjgoss]

I'm definitely supportive of having titles on links for the reasons you say, and that interface looks good to me.

The question is more how we map it to the Attachment message. I think the title can reasonably map to the fileName field. The MIME type is trickier - currently we use text/uri-list and for multiple links we newline-delimit them in the same attachment. We'd need to change this for multiple links with titles.

I think the best option is probably to emit one text/uri-list attachment for each link with a title, and make sure the HTML formatter does a good job of rendering consecutive link attachments without wasting vertical space.

What do you think?

[vitalets]

I think the best option is probably to emit one text/uri-list attachment for each link with a title, and make sure the HTML formatter does a good job of rendering consecutive link attachments without wasting vertical space.

Yes, I agree - a separate attachment message for each link.

In that case, if I still call it with pure urls, how many attachments will be added?

this.link(
  'https://github.com/cucumber/cucumber-js?param=value',
  'https://github.com/cucumber/cucumber-jvm?param=value',
);

I think, for the consistency and less maintenance efforts, it's better to behave in the same way - output several attachments even for pure urls.

One internal concern here is that text/uri-list will always contain a single link, not a list (as it's name assumes). There can be text/uri mime-type for adding a single link, that can gradually replace text/uri-list.

[davidjgoss]

I tend to agree re making it one URL per attachment.

There can be text/uri mime-type for adding a single link, that can gradually replace text/uri-list.

The reason for text/uri-list originally was that it's a standard. I think if we deviate then we should make clear that it's non-standard e.g. text/x.cucumber.uri+plain which mirrors what we did for text/x.cucumber.log+plain.

[vitalets]

The reason for text/uri-list originally was that it's a standard.

I didn't know that. Then I'd better vote for sticking to standard. List of a single element is still a list.