Experiment. What do you do when your beautifully designed large headings seem a little overwhelming against those inevitable small stories? Well, first of, try a little redesign maybe? But then... if the problem persists, perhaps we could get a little... funky with :has().

What if the hierarchy design of your headings was based on the needs of your content. Say, if your content has 4 different levels, then having a clear difference between them makes sense, and the high contrast between the h1 and the paragraph may not feel strange at all. But if you're only dealing with 1 or 2 levels then that contrast will be harsh so... do we need it?.

The Code

For this to work we're relying on the hopefully soon to come :has() pseudo-class. In the meantime we rely on a polyfill by Philip Walton to bring this to all browsers.

The Experience of Content Creators

When working with lots of users it can be hard to explain —and even harder to enforce— the use of appropriate heading levels, that are structurally logical, vs. good looking headings, that are aesthetically pleasing to their content. So then you end up with content pieces that jump from an h1 to an h4 simply because the design of that h4 is more pleasing to the given content than the h2's in comparison.

One way to approach this issue is by doing what I've presented above. Headings that have their styles adapt to the hierarchy needs of the given content. The headings only grow as large as they need to, thus removing this train of thought from the user.

Any Other Options?

Now this alone wouldn't be sufficient to tackle an issue like this —if it's even an issue, rather than just bad user practice. We could take this a step further by switching to an interface that puts emphasis on structure, such as Markdown. Which removes all distractions that come with a design and let you focus on the words, on the content. This could even make users think more carefully about what they're actually communicating possibly leading to richer texts and more fleshed out pieces.

Additionally, this could of course go into a whole other topic about creating an interface that doesn't exist and which may not need to exist.

Possible Issues?

Consistency across pages was pointed out to me as a main factor as to why this approach could fail. Design systems do of course require standards and changing the expectations of what the headings will look like from one page to another seems like a HUGE ask. This may require us to scale this down to very specific cases or to come up with exceptions, e.g., maybe the h1 design is unmutable so it remains consistent across contents of the same type.

Anyway... just a thought experiment. Let me know what you think.