CSS directive?

[tavin]

I'm working specifically in myst-enabled jupyter notebooks (or potentially the markdown previewer if it is myst-enabled).

Would a CSS directive be in the realm of possibility?

```{css}
```

And of course you would be able to write inline CSS and/or give a stylesheet reference. I've tried to pull this off indirectly (via html) with eval-rst, raw, and even raw-cell but probably all of these are only meant for building output docs with cli tools.

[choldgraf]

Have you tried a <style> block just directly in your markdown? I'm not sure if the parser will then apply it or not but it is worth trying!

[fwkoch]

Hey, I can shed a little light about what is going on here, at least in the jupyterlab myst plugin:

When parsing myst cells, we use the htmlPlugin to convert any html to myst prior to rendering (this transform uses rehype and is extendable with additional html handlers - see myst-transforms). At this point already, we have no handler for converting <style> to myst, so the html is lost.

If we provided an option to disable this transform, the <style> html would persist, but the rendering via myst-to-react would escape the html content and chuck it in a <span>, so it would just show up as text.

---

Thinking through this, there isn't a trivial solution.

• We could add a "myst-native" way to do style/css. This could then be used by (1) a css directive (as introduced in the original question) and/or (2) an additional html handler for <style> passed to the htmlPlugin.
• We could also keep it as html all the way through, and render it directly in the page (rather than escaping it). This would meet the expectation @choldgraf expressed above. However, doing this with arbitrary html is unsafe, so I'm not really sure what it would look like in the jupyter environment (or if it is even feasible).

[agoose77]

I think another aspect to this is that the benefit of using MyST is that we can use structured directives instead of HTML. This means that the ecosystem benefits from the ability to convert between representations, and the document can be more deeply expressive than an arbitrary block of semantic-free HTML. I assume that CSS falls somewhere in that box; it probably can be more gracefully ignored than e.g. HTML, so if some renderers ignore it, perhaps that's fine. I suppose this is where @rowanc1 et al. might have thoughts about where styling fits into this space.

[rowanc1]

Some of the other feedback that we have got from users of the JupyterLab MyST plugin is that we need to handle HTML how CommonMark handles it, which is just go straight to the page in an unsecured way. That is similar to how the standard renderer works in Jupyter, allowing a lot of flexibility but is basically impossible to translate into other formats that aren't HTML.

Overall, I think that is fine though, and we can change the renderer in JupyterLab MyST to be less secure and more like the original, and when exporting to other documents we do our best effort at translating the HTML as @fwkoch described!

[tavin]

For context, my primary motive here was to monkey patch glitchy upstream CSS. Another use case might be live previews of custom admonitions. Rendering to formats other than HTML is irrelevant in the 1st case and something I guess I would reimplement at a lower (python/latex?) layer in the 2nd case.

[tavin]

Btw if one does wish to address multiple output formats and security, is it a crazy idea to support a limited subset of SASS? Margins/padding, colors, font styles, etc.