Add scienceicon renderers

[brianhawthorne]

Enable CSF's {scienceicon} role (https://github.com/continuous-foundation/scienceicons?tab=readme-ov-file#myst-markdown) to render to React.

This is primarily in service of the tools.scientific-python.org site conversion to myst (scientific-python/tools.scientific-python.org#81).

It is also a move in the direction of solving this standing myst-theme issue: #362

---

• closes Render icon links with a role for use in 'parts' #803

[changeset-bot]

🦋 Changeset detected

Latest commit: 76eecdb

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

This PR includes changesets to release 15 packages

Name	Type
@myst-theme/site	Patch
@myst-theme/providers	Patch
@myst-theme/frontmatter	Patch
@myst-theme/diagrams	Patch
@myst-theme/jupyter	Patch
@myst-theme/styles	Patch
@myst-theme/common	Patch
@myst-theme/icons	Patch
@myst-theme/search	Patch
@myst-theme/search-minisearch	Patch
@myst-theme/landing-pages	Patch
@myst-theme/book	Patch
@myst-theme/article	Patch
myst-to-react	Patch
myst-demo	Patch

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

[netlify]

✅ Deploy Preview for myst-theme ready!

Name	Link
🔨 Latest commit	76eecdb
🔍 Latest deploy log	https://app.netlify.com/projects/myst-theme/deploys/698e154007a5d70008e8204a
😎 Deploy Preview	https://deploy-preview-752--myst-theme.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[choldgraf]

I think it'd be helpful if we let users easily define scienceicons in the book/article themes 👍 . Based on this implementation, it seems like we don't actually add any user-facing functionality, right? They'd still need to follow these instructions on their own from the science icons docs:

Copy the file scienceicons.mjs from dist/ intoyour local mystmd project and add it to the list of plugins in myst.yml:

project:
  plugins:
    - scienceicons.mjs

I also suspect that if they did this, and then wrapped the icons in a link (which seems to me the most common use-case), that they'd inherit the blue link syntax we use for prose. That feels suboptimal as well - we'd probably want "theme styling" for scienceicons when they're used.

Depending on our implementation, this might need a change in scienceicons since they don't emit a CSS class name w/ the icon so we can style it (e.g. class=csf-science-icon or something). Alternatively, the myst-theme could define its own way to use scienceicons in a button or something, but that feels like unnecessary duplication if possible to avoid.

Could we enable more "out of the box" functionality here by either:

1. bringing this plugin along with the theme, and defining some theme-specific CSS to make sure they look nice (standalone, as links, etc), OR
2. documenting how a user is expected to display their own scienceicons by loading the plugin themself (and confirming this works in our docs)

@rowanc1 what's your vision for how we should bring in functionality for scienceicons? Should it be all baked into this theme and out of the box? (e.g. so that anybody that uses these themes gets {scienceicon} roles for free?) Should it instead be user-enabled via plugin config, and this theme simply knows how to render the icons if they do this?

[agoose77]

On the topic of loading plugin support, I am in favour of enabling themes to define plugins for mymstd. I think that's a really interesting idea, even though it slightly muddies the mostly one-way interaction between mystmd and themes (i.e. affects how easy it is to swap out one theme for another with pre-built content).

We should likely think about scienceicons in the context of other icons like material icons: https://github.com/jupyter-book/mystmd/blob/main/packages/myst-ext-icon/src/index.ts

We have defined a role to parse these, but it's not hooked in to the theme or the engine yet. There were some pain points at the time in loading icons without blowing up the bundle size that we were discussing, and it's been on the back burner since.

The more things like icon packs we add, the more important it becomes to be able to somehow prune these back. Normally tree shaking does this, but because the theme is not a compiled-up-front application w.r.t content, we don't get that for free.

[choldgraf]

@agoose77 what do you think is the best path forward for this PR? We could add it in as a step forward for now? My interest in this is that we'd be a step closer to #362 without adding any new config surface area (instead, users would need to add a plugin).

To me the ideal use-case would be that a plugin can define both the roles/directives/node types that get put in the AST, and rules for rendering those nodes in various contexts. That's a step closer to our goal of mystmd/themes having a less opinionated base setup, and relying more on extension points for extra functionality. But it feels like we aren't there yet

Maybe the MIMEbundle conversation is related to this? If a new node had a MIMEbundle-like thing inside, then a renderer could step through that bundle to decide how to render it even if it hadn't been explicitly told how to do it. If you combine that with the ability to ship things like PNGs with plugins then you could probably get pretty far.

[choldgraf]

I wanted to demonstrate what I meant by needing another plugin, so just pushed a commit to explain what I mean. It makes minor modifications to the theme so that we can render scienceicons with a little bit of styling via a CSS class. If we want to revert that commit or remove parts of it, no problem from me!

It:

• Adds a little plugin that piggy-backs on scienceicon and emits an extra span with a class we can style.
• Adds a special renderer for that as well (this is a hacky part we probably want to remove)
• Documents scienceicon support and demos it in our sidebar.

Take a look at it here:

🖼️ icons reference page