Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to render <a> anchor tags with target="_blank" and rel="noreferrer"? #20

Open
JoshuaKGoldberg opened this issue Aug 5, 2024 · 3 comments

Comments

@JoshuaKGoldberg
Copy link
Contributor

JoshuaKGoldberg commented Aug 5, 2024

I'd like to use this library to render some markdown that might have links to external pages. For those packages, it'd be good to render anchors with target="_blank" rel="noreferrer". But I can't figure out how to inject thatm.

The options: any from this package seem to point to https://docs.astro.build/en/reference/configuration-reference/#markdown-options... is that right?

Is there a sanctioned path with @astropub/md to add attributes to specific tags? If not, could we make one?

@connor-baer
Copy link

connor-baer commented Aug 11, 2024

Since this package integrates with Astro's default Markdown configuration, you can use rehype and remark plugins to add the desired attributes. rehype-external-links should work well for your use case.

// astro.config.js
import { defineConfig } from 'astro/config'
import markdownIntegration from '@astropub/md'
import externalLinks from 'rehype-external-links'

export default defineConfig({
  integrations: [
    markdownIntegration(),
  ],
  markdown: {
    rehypePlugins: [
      [externalLinks, { rel: ['noreferrer'], target: '_blank' }]
    ],
  }
})

@JoshuaKGoldberg
Copy link
Contributor Author

That works site-wide, I don't think that's quite what I'm looking for. Setting the behavior for all links might not be desirable. Is there a way to set specific settings in one <Markdown.Inline ... /> component / markdown.inline( ... ) function call?

@connor-baer
Copy link

connor-baer commented Aug 12, 2024

Hm, looking at the source code, this would require creating a fresh markdown processor for each invocation of the markdown function to be able to pass it a custom markdown config. That has performance implications (see #16), though that could be mitigated by only creating a custom processor when custom options are passed and reusing the global processor otherwise.

(I'm not a maintainer of this package, only a user, so please take this with a grain of salt)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants