RFC: Create web components for standard html elements

[gfellerph]

Reasoning

There are some pros and cons, why we should build Custom-Components for standard HTML-Elements, such as button, etc.

Pros:

• We can define a standard behaviour in the Custom-Component.
• DEVs do not need to know every CSS-Class, internal HTML-Structures or whether attributes can be combined or not.
• We can provide a more consistence User Experience between all the Components.
• Styles are capsulated.
• Some JS logic can be abstracted away.

Cons:

• It can be hard to build a Custom-Component which reflects a standard HTML-Element.
  • There are a lot of specs to pay attention on to provide a correct Component (W3C, a11y, etc.).
  • We need to find a solution to provide some kind of Attribute heritation.
  • We need to find a solution to make events work correctly with this Components.
  • We need to find a solution to make ScreenReaders work correctly with this Components.
• The added value for devs may be too low.
• It is possible, that such Components are to static/not dynamic enough for our DEVs.

input from @oliverschuerch at #603

How are others doing it?

Analysis is done for the button component. Is it a web-component or is a standard <button> or <input> being used with CSS?

System	Componentize everything	Componentize only necessary elements
Swisscom SDX	✔
AXA	✔
PostFinance	✔
SBB (Angular Directive with native button)	⭕	⭕
Decathlon Vitamin		✔
Adobe Spectrum	✔

[gfellerph]

Web components help abstract complexity and are generally favoured for everyday usage. However, there are edge cases where a web component bring unnecessary complexity (imagine a third party plugin that can't access a button inside the shadow dom for event binding). Having standards HTML & CSS available in this situation is life saving.

A solution is preferred where web components (including for elements like button) exist alongside styled standard elements. Both implementations should share a base set of styles for extra dryness and consistency.