[Suggestion] Avoid using social-links-list class, as it may be blocked by EasyList

[nshcr]

Describe the bug

The EasyList social filter rules include .social-links-list selector, which causes certain elements on VitePress pages to not display properly.

Here’s the affected component code:

vitepress/src/client/theme-default/components/VPNavBarExtra.vue

Line 58 in 827259b

<VPSocialLinks class="social-links-list" :links="theme.socialLinks" />

Here’s the source of the EasyList rule (Be cautious when accessing this file — it’s quite large and may crash your browser):
https://github.com/easylist/easylist/blob/053fcd167ec66bd798cb9c3dde99c2906b1ffde8/fanboy-addon/fanboy_social_general_hide.txt#L8004

Reproduction

When ad blockers like uBO or Adblock Plus have the social rules enabled, the affected element disappears.

Disabling the relevant rule restores them to normal.

Expected behavior

I'm aware this is a Fanboy rule and not enabled by default, but ad blockers often make it easy for users to enable it. Renaming the class to something not on the blocklist is a simpler and more practical workaround.

Changing it to social-links-items should work, though in the long run, it might be better to avoid using names like social-link altogether.

System Info

Not necessary.

Additional context

No response

Validations

• Check if you're on the latest VitePress version.
• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[brc-dd]

It's bit hard to workaround that stuff. We can try changing, but that might also end up on some filter list. The only robust way is to obscure the class names (like use hashes) but it makes it almost impossible for others to override stuff reliably. Also, I think the people using that filter expect social links to be not shown, which is exactly what happens, so not sure if we should even change it.

[nshcr]

Currently, VitePress has three responsive layouts for different browser widths:

1. At the widest width, the social links are fully displayed — no filtering issues.
2. At the narrowest width, the social links are placed in a dropdown menu — no filtering issues.
3. At medium width, the social links are placed in a dropdown menu — but they get blocked by the filter.

I raised this issue because I noticed this inconsistent behavior, which led me to investigate and trace it back to the EasyList rules. I believe this is clearly a case of false positive blocking.

It's bit hard to workaround that stuff. We can try changing, but that might also end up on some filter list. The only robust way is to obscure the class names (like use hashes) but it makes it almost impossible for others to override stuff reliably. Also, I think the people using that filter expect social links to be not shown, which is exactly what happens, so not sure if we should even change it.

You’re right — there’s no need to get into a tug of war with ad blockers. However, I believe sites built with VitePress were never meant to be their target. My main reason for blocking social links is to block potential tracking behavior on certain sites, not to block community links or the social media accounts of users I’m interested in.

In fact, most tech sites’ social links aren’t blocked — Nuxt’s social links are even on the allowlist — but major VitePress sites like the Vite and VitePress official documentation are getting blocked. This can easily be mistaken for a bug on the site.

https://github.com/easylist/easylist/blob/2bf38873ee2f383203209c763e17e914e3a63736/fanboy-addon/fanboy_social_allowlist.txt#L44

[brc-dd]

At the widest width, the social links are fully displayed — no filtering issues.

They have social-links class:

This is skipped quite by luck though, as only #social-links is present on the list not .social-links.

Also, this will be a breaking change as many people are using it to add custom styles - https://github.com/search?q=vitepress+/%5C.social-links/+NOT+is:fork+path:/(?:s?css%7Cstyl%7C%5Bjt%5Dsx?%7Cvue)$/&type=code

We can maybe change it along with the v2 theme rewrite.