(web-components) Use ElementInternals for Button elements

[radium-v]

Previous Behavior

Currently, form-associated custom elements use the FormAssociated class mixin. This mixin is heavy and duplicative, being copied wholesale for every component which utilizes it. While FormAssociated includes minimal support for ElementInternals, the implementation isn't fully baked.

New Behavior

Improvements:

• Switches the <fluent-button> custom element to use ElementInternals by default. An optional polyfill may be added in the near future, as more components transition to use ElementInternals.
• Removes the checkbox-like implementation from <fluent-toggle-button> in favor of leaning on aria-pressed (an element with a role of button and the aria-pressed attribute is treated as a toggle button).
• Adds Playwright tests for the Button element.
• Synchronizes the <fluent-menu-button> and <fluent-compound-button> elements to work with the changes in <fluent-button>, since their classes are extensions of Button.
• Copies the original button styles into the stylesheet for <fluent-anchor-button>. The AnchorButton class isn't actually extended from Button but it did use the same stylesheet. Its template structure hasn't changed.
• Adds a story for submit- and reset-type buttons to the Button story file.

Other fixes:

• The Playwright config had a few minor misconfigurations:
  • The projects field was set to run all tests in Chromium three times in a row.
  • The viewport width and height values were flipped.

[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.

[Hotell]

Some workflow notes:

bumping deps and adding prodcution changes should be ideally done in N separate PRs as it's unrelated.

this would be more likely a blocker if this PR would be against master branch but for you case I leave that decision up to you as it doesn't effect daily monorepo contributions.

[Hotell]

FYI:

this is ok to live in wc3 branch.

if this would be against master we would most likely not accept this, as the cost of prolonging pipeline just for sake of 1 package is not worth the slowdown. If whole monorepo moves to use playwright for all e2e in feature then it's totally valid.

For this use-case we would need to make this on-demand as we do within fluent-contrib https://github.com/microsoft/fluentui-contrib/blob/main/packages/nx-plugin/src/executors/playwright/executor.ts#L51-L54

[radium-v]

How are the Playwright binaries currently made available for existing packages which use Storywright?

[Hotell]

why is this change necessary ? another exotic tsconfig === more confusion / not following repo patterns

[radium-v]

The API Extractor doesn't use the tsconfigFilePath if any overrideTsconfig fields are present. This was causing warnings "Subsequent property declarations must have the same type" (TS2717) with @types/web present.

[Hotell]

approving as it's for wc3 branch. these changes would not be acceptable for master - added more context in comments for better understanding. ty