Adds dataLanguage property to the replacement <pre> element.

[604qgc]

Changes

• Passes the language info used by the highlighter (languageMatch?.[1] || "plaintext") as dataLanguage property to the replacement <pre> element.

Testing

No testing other than verifying that the property is passed down properly; unsure what/how to test for such thing.

Docs

When using Astro's built-in markdown processing, the built-in code highlighter processes the data first, before any other remark/rehype plugin can. The Shiki highlighter does not pass around the language information in its output.

This change fixes this and will allow users using the built-in Shiki highlighter to collect the coding language info after Shiki has passed.

Since it standardises the way the language info can be retrieved between Astro's two built-in highlighters, it will allow switching between the two while preserving this feature with no intervention (currently only Prism supports passing down the language, using className).

This should not break anything for users, unless they already use a dataLanguage property on <pre> elements as well as the built-in markdown processing.

The language info can then be retrieved in a rehype plugin like so:

// myRehypePre.js
import { visit } from "unist-util-visit";
export default function myRehypePre() {
  return (tree) => {
    visit(tree, { tagName: "pre" }, (node) => {
      const lang = node.properties.dataLanguage;
      [...]
    });
  };
}

[changeset-bot]

🦋 Changeset detected

Latest commit: 52f3cd7

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[bluwy]

Sounds good to me. We also have a roadmap request for this: withastro/roadmap#276

[bluwy]

I'll put this in the 4.6 milestone since we're near it. It should be merged on this Wednesday.

[matthewp]

can you add a usage example?

[matthewp]

Before merging we would like a usage example in the changeset.

[604qgc]

Added new commit that solves this: #6869

(Sorry, I pasted the wrong link in the commit message and it can't be safely overwritten from what I understand).

It's more or less the same thing as my first commit, but for the Code component. The trick is that because the Code component uses Fragment, the html gets flattened and the <pre> cannot be accessed easily in remark/rehype plugins. So the only thing it does is expose the data-language in the rendered html.

That allows css rules like this to work when using the built-in Code component:

pre::before {
  content: attr(data-language);
  // ....
}

To be clear, the first commit does the same thing + allows to catch the data-language when working with the node tree, for fenced-code in .md/.mdx files.

For example, we would expose data-language="python" from the following:

\```python
def func():
    print('Hello Astro!')
\```

Since the first commit and this one solve the same issue, I think it'd makes sense to bundle them together.
What do you think?

Regarding the usage example in the changeset, what should it look like? Should I copy the above and the rehype snippet from my first message?

[bluwy]

Good catch 👍 Now that I see it, maybe we can do the fix differently. We can remove the current changes, but add the data-language at:

astro/packages/markdown/remark/src/rehype-prism.ts

Lines 11 to 13 in 799f6f3

	return Promise.resolve(
	`<pre class="${classLanguage}"><code is:raw class="${classLanguage}">${html}</code></pre>`
	);

astro/packages/markdown/remark/src/shiki.ts

Lines 103 to 104 in 799f6f3

	// Replace "shiki" class naming with "astro-code"
	node.properties.class = classValue.replace(/shiki/g, 'astro-code');

Code.astro currently uses the second linked code so the changes would auto-propagate there. That way I think we can continue use the same changeset.

[sarah11918]

Suggested change

	Adds a `data-language` attribute on the rendered `pre` and `code` elements to expose the highlighted syntax language
	Adds a `data-language` attribute on the rendered `pre` and `code` elements to expose the highlighted syntax language.
	This allows retrieving the language in a rehype plugin:
	```js
	// myRehypePre.js
	import { visit } from "unist-util-visit";
	export default function myRehypePre() {
	return (tree) => {
	visit(tree, { tagName: "pre" }, (node) => {
	const lang = node.properties.dataLanguage;
	[...]
	});
	};
	}
	```

Hi @604qgc ! I was thinking of including something like this in the changeset, since for minor releases of new features we do like to show them off a bit and really help people understand why your thing is cool! 💅

I took this from your PR description, but if there's something else you'd prefer to use, or would change this in some way, please do! I think a changeset of this style/length is helpful to people to understand the new feature, so anything like this you can suggest would be great.

[604qgc]

Thank you @sarah11918 !
I added some more notes for clarity, but happy to trim if that's a bit too long db66313

[604qgc]

@bluwy Ah yes indeed!
Rolled-back initial changes and committed new fix, all working as expected 👍

[bluwy]

Looks great!

Changeset added, with examples

[sarah11918]

Thank you so much @604qgc! Admittedly, I think this feature does seem cooler know that you've been able to share more about it... and that's what we want! 😄 The addition of the CSS mention is fantastic!

I just left a couple of wording suggestions for your consideration. Now that this is longer with examples, I tried to make the text itself more concise and direct. See what you think!