Adding properties to the body tag with `rehypeDocument` #191

Didericis · 2025-03-12T17:45:02Z

Didericis
Mar 12, 2025

I have a project where I'd like to be able to theme the output, and would like to do that by adding a class to the <body> tag with the appropriate css class for the theme.

I opened a PR that adds the feature here to optionally specify properties to add to the body tag (like class).

Any objections?

JounQin · 2025-03-12T17:47:14Z

JounQin
Mar 12, 2025
Collaborator

Why not just write a tiny plugin for your own useage then?

1 reply

Didericis Mar 12, 2025
Author

The existing options to add meta tags, link tags, style tags, etc with custom properties suggested there'd be an option to modify body as well: I was expecting there to be an option for this/it's the first place I looked when I needed to add a class to the body, as it seems in scope for what this plugin does already.

wooorm · 2025-03-17T11:44:32Z

wooorm
Mar 17, 2025
Maintainer

Heyy there!

I understand that you look for this, but looking at the current options, rehype-document has to do with hidden things, metadata.
If we start adding properties for body, we could add properties for <html>, <head>, <title>, and then we could insert an h1 and then classes for header and footer, and ... so many things!
Most options here are specific properties (dir, language) or are about creating lists of metadata elements: link, script, meta, style.

Back to your root question:
Which properties do you want to add?
Do those properties have to go on <body>?
Do you need this plugin (to turn a fragment into a whole document)?

3 replies

Didericis Mar 17, 2025
Author

Hey 👋 .

RE the general point about all the various different options that could be added, understood/I get the desire to keep this plugin limited. Since this plugin is the plugin that adds the body tag, to me it makes sense for the plugin to allow a user to also add custom properties to that body tag. Totally agree that adding options for things like header, footer, etc would be out of scope.

Which properties do you want to add?

My only current use case is the className property (for specifying what theme the app should use). I thought it'd be nice to give the user full control over any other properties they might want to add for the reason stated above (plugin is adding the body, so customizing the body seems in scope to me), but if you think that's too much and that it'd be better to just add an option like bodyClassName I can do that instead.

Do those properties have to go on <body>?

They don't have to (I could wrap all my content in a div with the class name instead, load different themes in other css files dynamically, etc), but I'd like to do this by applying a theme class to the top level element in the hierarchy. I think it makes the most sense to toggle themes by toggling classes on the body, so if this addition isn't wanted I'll probably either write another little plugin or keep using the fork.

Do you need this plugin (to turn a fragment into a whole document)?

Yes. Project I'm currently working on involves rendering little markdown snippets as webpages.

wooorm Mar 18, 2025
Maintainer

by applying a theme class to the top level element in the hierarchy

Why is the top-level element the <body>, and not <html>?

Do you have exact examples of what the values of your theme classes are?

Project I'm currently working on involves rendering little markdown snippets as webpages.

Would you not also (perhaps in the future) wrap some other stuff around the markdown?
A main, header, footer. Navigation. Search. Table of contents.

Often, people also wrap HTML-from-markdown in a .markdown-body class.

plugin is adding the body, so customizing the body seems in scope to me

So, I indeed agree with this: this project generates <body> (and <html>, <head>, <title>) so so options for those are here.

What I am wondering is whether there is a need for arbitrary properties on body.
Would that also extend to htmlProperties, headProperties, titleProperties?
Is it just bodyClassName?
Would that also extend to htmlClassName, headClassName, titleClassName?

Didericis Mar 18, 2025
Author

Why is the top-level element the <body>, and not <html>?

Fair point. I mean the top level container for all the content, excluding meta information. It makes more semantic sense to me to theme the content in <body>, as a theme wouldn't apply to anything in <head>. So applying it to the <html> element doesn't seem as appropriate.

Do you have exact examples of what the values of your theme classes are?

Right now it's just ancient-theme and modern-theme.

Would you not also (perhaps in the future) wrap some other stuff around the markdown? A main, header, footer. Navigation. Search. Table of contents.

Yep. I'm doing that already via some custom plugins, but I'm doing that before applying the rehypeDocument plugin, which is what wraps that content in a body tag.

Again, many ways to accomplish my specific use case without this addition. I just thought it'd be useful to be able to customize the body tag via this plugin at the time it's created and was expecting this feature to be there already.

What I am wondering is whether there is a need for arbitrary properties on body. Would that also extend to htmlProperties, headProperties, titleProperties? Is it just bodyClassName? Would that also extend to htmlClassName, headClassName, titleClassName?

Maybe, but I don't see a common reason for wanting to customize attributes on either <html>, <head>, or <title>. Custom attributes on <body> seems like a more common want (for theme classes and maybe data attributes that should apply to all content), and I didn't want to overly restrict customization to my specific use case. So I thought it made sense to just allow arbitrary customization of attributes added to the body tag.

Just to be clear, if none of this is winning you over and it seems a bit asymmetrical to allow customization of just one element instead of all the other elements added, or if modifying the body seems a bit strange/unconventional, fair enough. This won't block what I'm doing, and I don't want to push an unwanted feature. But to me it makes sense/was something I was expecting to be there.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rehype

Adding properties to the body tag with `rehypeDocument` #191

{{title}}

Replies: 2 comments 4 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

rehype

Adding properties to the body tag with rehypeDocument #191

Didericis Mar 12, 2025

Replies: 2 comments · 4 replies

JounQin Mar 12, 2025 Collaborator

Didericis Mar 12, 2025 Author

wooorm Mar 17, 2025 Maintainer

Didericis Mar 17, 2025 Author

wooorm Mar 18, 2025 Maintainer

Didericis Mar 18, 2025 Author

Adding properties to the body tag with `rehypeDocument` #191

Didericis
Mar 12, 2025

Replies: 2 comments 4 replies

JounQin
Mar 12, 2025
Collaborator

Didericis Mar 12, 2025
Author

wooorm
Mar 17, 2025
Maintainer

Didericis Mar 17, 2025
Author

wooorm Mar 18, 2025
Maintainer

Didericis Mar 18, 2025
Author