[Feature]: Add a props for link obfuscation

[JoPrignol]

Please take a moment to familiarize yourself with this project scope and standards

• I have read the Documentation and I understand how to correctly use this module.
• I have read the Contributing Guidelines.
• I agree to follow this project's Code of Conduct

Describe your idea

Adding an optional 'isObfuscated' prop taking a boolean value in order to make it possible to obfuscate links.
If a link is obfuscated, it will be displayed using a tag triggering a function that opens the link in a new tab. Otherwise, it would work as usual. This is useful for SEO purposes.

Contribution

• I am willing to contribute to the implementation of this feature.

[stefanobartoletti]

@JoPrignol Thanks for the suggestion.

The intended way to manage these SEO concerns is typically solved by using the correct values in the rel attribute, for example, by setting it to nofollow (and possibly, additionally, also to noopener noreferrer).

While I appreciate the time and effort you put into the PR you submitted, some concerns prevent me from accepting it:

• semantically, the correct tag for a link is an a. It is already recognized by the browsers as an element that carries a link and do not require any extra workarounds (i.e. using JavaScript to open a link, when the href attribute is the correct way to do it without extra code).
• for accessibility purposes, an a is already recognized by the browser as a link, and do not need any extra workarounds (i.e. to be correctly and natively tabbable, clickable, usable with a keyboard, precisely recognized by screen readers, etc...)
• considering boht previous points, the browsers natively expect a to be navigation links, both for internal and external ones, and button as an element that performs an action (submitting a form, toggling some UI, trigger JS actions, etc..). Using the wrong element may confuse browsers, assistive technologies, and search engines about what your element actually does.
• generally speaking, I tend to value clean, concise, and maintainable code over adding more complexity, if the issue may be solved in a simpler way.
• currently, adding a rel="nofollow" to your <SocialShare> component will pass it down, as per default Vue behavior, so not much extra code is needed for this to work.
• I'm not an SEO expert, so I can accept that there are use cases where your proposed behavior may be desirable and with a higher priority over my previous points and over cleaner code and implementation. For these situations, the module already exposes the composable with all data required to build your own custom button, if you really need it.

Feel free to give me your specific point of view, and your reasoning about why your proposed solution may still be worth considering for merge.

---

Anyway, since I have not explicitly mentioned this in the docs, I may also consider adding a rel attribute directly in the component template, with a default value of nofollow noopener noreferrer, which should provide common and sane defaults for any use case. Using a prop to accept custom values from the user, and having a default provided by the component will do.

If you feel like it and still want to contribute, maybe you can open another PR with this edit

[JoPrignol]

Thanks for the time you took to review my PR :)

I'm not an SEO expert myself, but I asked one about the rel="nofollow" solution you suggested. From what I understood, a kind of link exploration budget is allocated to each page when Google's robots explore it. A link having a rel="nofollow" attribute will be explored (so it will consume a part of the budget), but won't be linked to the page in the end. An obfuscated link on the other hand, won't be explored, and thus won't consume any link exploration budget. The obfuscation mechanism is thus justified by the fact that, for the same end result on those links, less link exploration budget will be consumed, leaving more of it for relevant links on the page.

However, it is true that the solution they suggested for link obfuscation is less than ideal from an accessibility and semantic point of view. I looked for a better alternative, but other than adding aria attributes to change the button's role, I found no 100% satisfying solution.

Another solution I found would be to implement a mechanism that renders those links as tags when a user is browsing the page, and obfuscate them when it's not the case (so when it's read by robots). However, this solution adds tons of complexity, and is not 100% reliable.

As for the possibility to add a rel prop with a default value to the component, it is indeed a good idea that i'd be happy to contribute to. I'll open a PR with this edit :)

[stefanobartoletti]

Added with #436