I wonder if some people would expect the attrs to be combined rather than overridden? Like if you have autogenerate: { attrs: { 'data-special': true } } and then within that a page with frontmatter like:

sidebar:
  attrs:
    class: experimental

Would you expect to get a <a data-special class="experimental">?

The argument against is that it makes it a bit harder to remove attributes. I guess you’d need something like this to remove an attribute:

sidebar:
  attrs:
    data-special:

Assuming something like this:

Nice catch! I'd expect the attributes to be merged, with page-level attributes taking precedence over others.

Good question. When working on the PR, I actually tried both approaches and found the overriding one more to my liking in the scenarios I was testing but I can definitely see how when you expect one approach, the other can be confusing (that's also why I mentioned it explicitly in the docs).

Happy to update the PR if more people think merging is the better approach, I'll do that tomorrow morning.

Thanks for the feedback 🙌

Would you mind sharing a bit about the detail of those scenarios? I always like to hear the concrete use cases as it can help understand better. My thinking was mostly based on a scenario like:

• autogenerate.attrs would be used for a unified control over a group of links, e.g. maybe these are your experimental docs, or reference, or some other category, and get a specific custom style to indicate that
• sidebar.attrs would be used for adding additional attributes for a specific page link, e.g. to flag a new page perhaps
• The group identity and the page-specific attributes aren’t necessarily exclusive: you’d want to keep both.

Admittedly, if that example was setting class for both, nothing would change here, because sidebar.attrs.class would still need to include the group class names, but for some other attributes it might make more sense, e.g. maybe there’s some group you set target="_blank" rel="noopener" for but don’t want to have to set those again in frontmatter just to add a class. (And to maintain — changes to the group config would need adding to all overridden pages and remembering that there are overridden pages.)

Open to convincing either way though — sounds like you had some specific scenarios in mind, so those might be valid.

My initial decision to override attributes was not really tied to the scenarios I tested but more to the overall experience when playing with them and overriding attributes at the page level:

• I found overriding easier as I was starting from a blank state, and just having to focus on "what exactly do I want as custom attributes for this page?" vs "ok, I already have these attributes applied defined in another file, here is what I want in the end, what do I need to remove and add to get there?"
• Removing attributes is not the obvious thing to do when merging attributes
• One example I tried was with the style attributes while the configuration was applying a class attribute. I kinda liked that my custom class was automatically removed when I set a style attribute, as it was not relevant anymore.

I've updated the PR to use a merge strategy so that we can play with it more and see how it feels.

One small note, I had to allow null values to properly support removing attributes from the frontmatter:

sidebar:
  attrs:
    data-special:
    data-special: ~
    data-special: null

All of these would result in a null value which we were not previously allowing.