feat(web-components/buttons): add support for essential anchor attributes

[malikarami]

Is your feature request related to a problem? Please describe.

This is how I am using the standard button to behave like an anchor:

      <a  
        href={reward.link.url}
        target="_blank"
        rel="noopener noreferrer"
        className={styles.link}
      >
        <TapButton variant="ghost" >
          some text
        </TapButton>
      </a>

I noticed that it can be used as an anchor as well by simply passing the href prop to it. But the problem is that, apart from target, I need to set other anchor attributes such as rel, But I can not as the property is not supported.

Describe the solution you'd like

I have two vague solutions on mind. Either defining all of the props of the a element for the standard button or creating another component that is exactly an anchor but supports all of the button skins.

Describe alternatives you've considered

Additional context

[amir78729]

Is your feature request related to a problem? Please describe.

This is how I am using the standard button to behave like an anchor:

  <a  
    href={reward.link.url}
    target="_blank"
    rel="noopener noreferrer"
    className={styles.link}
  >
    <TapButton variant="ghost" >
      some text
    </TapButton>
  </a>

I noticed that it can be used as an anchor as well by simply passing the href prop to it. But the problem is that, apart from target, I need to set other anchor attributes such as rel, But I can not as the property is not supported.

Describe the solution you'd like

I have two vague solutions on mind. Either defining all of the props of the a element for the standard button or creating another component that is exactly an anchor but supports all of the button skins.

Describe alternatives you've considered

Additional context

Thanks for raising this, @malikarami!

To clarify: when you set target="_blank" on an <a> element, modern browsers implicitly apply rel="noopener" for security reasons. This behavior is also documented on MDN:

• rel="noopener"
• rel="noreferrer"

So in most cases, you don't need to explicitly add rel="noopener noreferrer" when using target="_blank", as browsers handle noopener automatically.

Can you confirm if this implicit behavior satisfies your requirement? If yes, we can go ahead and close the issue.
Otherwise, if there's a specific use case where manually setting rel is still needed, we’ll prioritize adding support for that prop to our button components.

Let me know what you think! 🙌

[malikarami]

Thank you for pointing this out, @amir78729 . I wasn't familiar with this concept.

Putting that aside, I still believe the anchor element should have a distinct interface separate from the button, with full support for all anchor attributes. It doesn't seem appropriate that a button could change its behavior and transform into an entirely different element simply by setting an attribute—frankly, this surprised me. I checked MUI, and it seems their MuiButton behaves similarly; however, they appear to fully support all anchor attributes at least.

On the other hand, if your convention intentionally doesn't support all standard attributes of native elements—for example, if your button props intentionally represent a subset of native HTML button attributes—it makes sense not to include every anchor attribute immediately, instead adding them only as the need arises.

I'm looking forward to hearing your and @mimshins' opinions on this.

Thanks!

[mimshins]

@amir78729
@malikarami

We're enhancing the security and reliability of link-buttons that open in new tabs (target="_blank") by automatically setting rel="noopener noreferrer". This is crucial because noopener prevents the new page from potentially exploiting the original window, while noreferrer further protects user privacy by not sending referrer information. Although noreferrer already encompasses noopener, and older Firefox versions prefer its omission in such cases, we're including both for maximum backward compatibility.