add anchor as a new component to support anchor-button scenario

[chrisdholt]

Naming

For a variety of reasons, supporting two separate semantic elements within the ShadowDOM of a web component is less than ideal. With that, we need to find an approach to support scenarios for elements which functionally and semantically are anchors, but appear like a button.

From a verbosity standpoint, "anchor button" is the semantic that we tend to use to describe these. Fluent UI React v9 utilizes "as" to shorthand this assignment. Given this needs to be a separate HTML element, I'm proposing a shorter name than anchor-button and utilizing a class and tag name of simply <fluent-anchor>. A few key reasons for this:

• Anchor already exists in Fluent UI Web Components (stable) using the same semantic, construct, and approach.
• Anchor is shorter to write and less verbose considering devx and convenience
• There is no conflicting namespace. "Anchor" isn't a construct in Fluent components and "link" conveys a different semantic meaning.

Overall, it seems reasonable to simply go with the shorter name as it maintains an existing approach, there are no semantic conflicts in Fluent, and it's just plain easier and shorter to write.

Related Issue(s)

• Fixes #

[fabricteam]

📊 Bundle size report

_{🤖 This report was generated against 37195a34b36538ab0cc7c765824691bab796502e}

[size-auditor]

Asset size changes

Size Auditor did not detect a change in bundle size for any component!

Baseline commit: 37195a34b36538ab0cc7c765824691bab796502e (build)

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit d3f85c0:

Sandbox	Source
@fluentui/react 8 starter	Configuration
@fluentui/react-components 9 starter	Configuration

[miroslavstastny]

There is no conflicting namespace. "Anchor" isn't a construct in Fluent components and "link" conveys a different semantic meaning.

So we will have fluent-anchor (which looks like a button) and intrinsic a. If we ever add fluent-link my head will explode.

[chrisdholt]

There is no conflicting namespace. "Anchor" isn't a construct in Fluent components and "link" conveys a different semantic meaning.

So we will have fluent-anchor (which looks like a button) and intrinsic a. If we ever add fluent-link my head will explode.

I guess “link” is a legit instance and appearance we need to adopt isn’t it? I’m open to “anchor-button” but also, yuck!

[miroslavstastny]

There is no conflicting namespace. "Anchor" isn't a construct in Fluent components and "link" conveys a different semantic meaning.

So we will have fluent-anchor (which looks like a button) and intrinsic a. If we ever add fluent-link my head will explode.

I guess “link” is a legit instance and appearance we need to adopt isn’t it? I’m open to “anchor-button” but also, yuck!

I would understand the anchor-button more (because that's what it is). But will leave it up to you.

[chrisdholt]

There is no conflicting namespace. "Anchor" isn't a construct in Fluent components and "link" conveys a different semantic meaning.

So we will have fluent-anchor (which looks like a button) and intrinsic a. If we ever add fluent-link my head will explode.

I guess “link” is a legit instance and appearance we need to adopt isn’t it? I’m open to “anchor-button” but also, yuck!

I would understand the anchor-button more (because that's what it is). But will leave it up to you.

Given we have fluent-compound-button, fluent-anchor-button seems reasonable in terms of verbosity :).