fix: link-external-newwindow: true not respected by default listing

[mcanouil]

This pull request fixes the issue where the link-external-newwindow option was not being respected by the default listing type. The problem was occurring when generating the HTML for the listing items, specifically in the item-default.ejs.md file. The code has been modified to remove the "no-external" class from the anchor tags, allowing the link to open in a new window as intended when using link-external-newwindow: true.

Fixes #9468.

tested on:

1. quarto create project blog demo Demo
2. Add an externa.qmd

---
title: "Demo"
link-external-newwindow: true
listing:
  contents:
    - path: https://www.nature.com/articles/d41586-024-00692-7
      title: "China–US climate collaboration concerns as Xie and Kerry step down"
      author: Smriti Mallapaty
      description: "Gang's quote on the importance to continue the research exchange and colloboration 'If the river freezes over, water will still flow underneath.'"
      date: "2024-03-12"
      categories: [Nature]
    - path: https://www.scientificamerican.com/article/what-the-u-s-china-agreement-means-for-greenhouse-gas-emissions/
      title: "What the U.S.-China Agreement Means for Greenhouse Gas Emissions"
      author: 
        - Benjamin Storrow
        - Sara Schonhardt
      description: "The two nations announced limited steps to address climate change. But even a modest agreement could have far-reaching effects."
      date: "2023-11-16"
      categories: [Scientific American, E&E News]
  sort: "date desc"
  categories: true
  sort-ui: false
  filter-ui: false
page-layout: full
title-block-banner: true
---

FYI: the no-external class is not used anywhere else in the codebase but it is used in the following JavaScript
https://github.com/quarto-dev/quarto-cli/blob/main/src/resources/formats/html/templates/quarto-html.ejs#L366-L367

Should :not(.no-external) also be removed?

[cscheid]

I'm a bit confused about the fix here; I would have expected there to be a condition that needs to be checked depending on link-external-newwindow. How does removing that solve the problem without causing a problem with (eg) link-external-newwindow: false?

[mcanouil]

That's the thing I did not figure out yet.
The other listing templates are very similar in this aspect.

The option seems to be applied at another level as I did not find anything in src/resources/projects/website/listing. The only thing I found was the fact that it was explicitly hardcoded that links should never be opened in a new window and only within the default type listing.

Edit: this is why removing this class makes the external new window option works. The option is used as part of a JavaScript script which is added to HTML when the option is true.

• quarto-cli/src/resources/formats/html/templates/quarto-html.ejs

  Lines 375 to 381 in 1ec0115

  	<% if (linkExternalNewwindow) { %>
  	// target, if specified
  	link.setAttribute("target", "_blank");
  	if (link.getAttribute("rel") === null) {
  	link.setAttribute("rel", "noopener");
  	}
  	<% } %>

[cderv]

Just a note that this PR is exactly a revert of commit 8c61f7e

So I don't know exactly why it was added this way with no-external, but it seems it was done on purpose. I'll ask Charles as he is around.

[mcanouil]

Yes, I was looking into it to find what was the reason for this to be done only in the default.
I did not find any issues or smoke tests related to this. I also did quite few tests and did not find any downside of not having this class.

@dragonstyle in case you recall why you did add the .no-external class for all links in the default listing item template.

[mcanouil]

Do not merge.
I want to investigate a bit more.

[mcanouil]

I've tested on various website listings (6) and did not see any issues.

[cderv]

I believe what needs to be tested if all the feature that removing no-external would trigger
https://github.com/cderv/quarto-cli/blob/adef941f451f3ce8443ebf68e2f310e57b07b4be/src/resources/formats/html/templates/quarto-html.ejs#L365-L395

From the code it seems to mean

• External new window adding noopener
• External icon adding an icon on the link

Currently, both of this won't happen to links with .no-external

After discussing with @dragonstyle last week, he does not remember why exactly but was warning us that it could have been made following some slack discussion for some of our doc website, and that it could trigger other stuff.

Now, things may have changed since then, and maybe removing the class won't trigger anything bad 🤔

[cderv]

For example, this is how it looks if I add link-external-icon: true

We got an icon everywhere - and I don't think we want this really

[mcanouil]

Indeed, that might be the issue Charles tried to fix.

I think the "noexternal" fix is wrong. Wrong in the sense that other listing will have the same issues.
I believe, the right fix is to not add the external icon for links in listings (except if they are in the "description").

What do you think?
If this sounds good I'll tinker around that idea.
Meanwhile, putting this PR back in draft.