feat: Add target attribute to links in listing templates if provided

[mcanouil]

Enhance the listing templates by conditionally adding a target attribute to links.
This allows for better control over link behaviour, enabling users to open links in new tabs if specified.

---
title: "12276"
listing:
  contents:
    - path: posts/post-with-code/index.qmd
      target: _blank
    - path: posts/welcome/index.qmd
  sort: "date desc"
  type: default
  categories: true
  sort-ui: false
  filter-ui: false
page-layout: full
title-block-banner: true
---

Screen.Recording.2025-03-14.at.21.43.08.mov

Originally discussed in:

• How to open listing items in a new tab when using reveal.js slide shows? #12276

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[cderv]

Thanks for the addition.

If I see the value of the feature, I am wondering if this is best field name. target is a bit broad when you don't know about the usage.
And it opens also question for other link attribute. For example, with target="_blank" you usually want to add rel="noopener noreferrer" for security.

It fiels a bit weird to have such fields that controls listing links rededring at top level.

But that is just first impression here. I am thinking about better organization or naming.

For example, what if need to allow aria-label addition for those link ? if it should be controlled by user, it would be another field ?

I wonder if we should have something closer to manuscript code-links
https://quarto.org/docs/manuscripts/components.html#code-links

listing-link:
  target: "_blank"
  rel: "noopener noreferrer"
  aria-label: "Opens in new window"

This would allow adding schema maybe.

Also, doc related: this is kind of a special metadata field that needs to go into the list of known ones
https://quarto.org/docs/websites/website-listings.html#listing-fields

I think it is good to always have doc in mind which each PR.

This is the kind of PR that seems simple to fix, but requires some thinking for best long term behavior.

Regarding code review, you need to be thorough. I believe if you add a field to template you need to update that part too

quarto-cli/src/resources/projects/website/listing/item-default.ejs.md

Lines 2 to 12 in 9c6d652

	// Fields
	const fields = listing.fields;
	// Image properties
	const imageAlign = listing['image-align'] || 'left';
	const imageHeight = listing['image-height'];
	// Fields that don't have a known place to be displayed in this template
	const otherFields = fields.filter(field => {
	return !["title", "image", "image-alt", "date", "author", "subtitle", "description", "reading-time", "categories"].includes(field);
	});

Otherwise the field will end up in a metadata-value div, which I don't think we want here right ?

Anyhow, open to discussion.

[mcanouil]

You're right that target should be added to the undisplayable fields list (not in the template side) to prevent it from appearing when using pure metadata-sourced listings or custom templates.
I'm fixing it, but I believe it should be in:

• quarto-cli/src/project/types/website/listing/website-listing-read.ts

  Line 560 in e28f73a

  const undisplayable = ["path"];

[mcanouil]

Also, doc related: this is kind of a special metadata field that needs to go into the list of known ones
https://quarto.org/docs/websites/website-listings.html#listing-fields

I think it is good to always have doc in mind which each PR.

This PR is one year old and as you pointed needs a bit of discussion to generalise it (also why I initially added the label).

---

Few notes:

• The "noopener" ("noreferrer" does not seem to be used) is also missing for Manuscript code-links (repo, devcontainer, binder).
• If an interface for "links" is created it could be used more thoroughly in the codebase. This would require a bit more work but seems worth it to have consistency.

[cderv]

If an interface for "links" is created it could be used more thoroughly in the codebase. This would require a bit more work but seems worth it to have consistency.

Yes, that is why sometimes a feature that seems nice and easy to do can lead to more design question, and more thoughts needed. Generally why contributed feature PR takes time to review and think about.