Writing room h1..h6 styling -- can they be made more distinct?

I've written a custom type for a header menu. I'm annoyed again that there's no support for more than one level of nesting (can't have a group within a group, and can't have a group within a slice), and so I've worked around it by having a flat list of items, each one declaring its intended depth in the menu structure.

I thought it'd be neat to declare the intended nesting level for each item by the heading level of its title, rather by adding another field.

This works well. The only problem is that it's hard to tell at a glance which heading level is which. The styling only has minimal font size differences between the heading levels.

This screenshot shows a mixture of h1, h2, and h3, and it's very hard to tell which is which. I have to click on them and check the formatting bar to be sure.

This is a request to make the heading levels more distinct in the writing room. Perhaps the font size differences can be greater, or utilize different font weights?

Hi @bart,

Thanks for this feedback! I changed the category of the thread to "features," and submitted this as a feature suggestion to our product team.

For a three-level header menu, this is how we've dealt with the same challenge before:

Let me know if there's anything else I can do :slight_smile:


Thanks for pointing that out.

But honestly it seems no better. Worse, even, in my opinion. In that example you have a slice type for top-level items, and another slice type for second-level items with third-level items shoehorned into its repeating area. And still with no validation -- nothing to stop someone starting off with a second-level item.

Yeah, I don't like that at all. It's a hack, and so is my version.

This isn't really relevant, though. I'm asking whether the styles of h1..h6 can be made more distinct from each other. The menu example above was just showing a use case where I want to tell at a glance which level the heading is. But the same could be said for an arbitrary rich text field.

Hey Bart,

I hear what you're saying. Perhaps the least-hacky option would be to make a tree of multiple documents using content relationships. That would force editors to follow the right structure, but it also might clutter your repo and create a cumbersome editing experience. (I generally wouldn't advise using a lot of content relationships, for that reason.)

There's no built-in functionality in Prismic to make the heading styles more distinct in the writing room. It's good to know that you're having trouble distinguishing them — it's likely something we'll want to improve, so I'll encourage the UX team to look into it.

In any case, please let me know what your final solution is! It's always good to know how developers are innovating.


Yeah, absolutely not. That would be a nightmare for the content editor. And for me too -- imagine the headaches when items are linked but not published, and so on. I bet querying for it would be painful too. But again, this thread is not intended to be about nesting data structures. Here's a different thread asking for the same thing; I'd add my voice to that if it weren't closed. Deeply Nested Fields

I know. I'm asking you to change the writing room stylesheet.

Don't you find them hard to distinguish? Body size is set to 14px, and then h1, h2, h3 are all significantly larger but very very close to each other, at 26px, 24px, 22px. I haven't seen any accessibility guidelines for distinguishable size differences where they matter, but if there were any, I'd bet these sizes didn't meet them.

Yes, I hear what you're saying, and I've relayed this to the product team.

We're also having lots of conversations internally about how to handle nested data structures, such as for a three-level nav. Hopefully we'll have some updates on this for you in the future :slight_smile:

1 Like

This is being tracked as an open feature request.

If you have another use-case for this feature, you can 'Flag' this topic to reopen. Please use the :heart: button to show your support for the feature and check out our Feature Request Guidelines.