Simplify our form input designs

[Febakke]

All inputs will soon be one component with different types in code. For exampple input type=text. This means they will all use the same component tokens in code. To day we are handling states different on different components. Can we make them simpler and more alike?

•  What is different between our form components today?
• What can be simplified?
• new read only design

[mrosvik]

Investigate: Should we have hover state on input components? #2632

[eirikbacker]

Simplifications for our input components:

Skip using hover:

• Hover is usually not provided on input elements - both textual inputs and toggle inputs such as radio, checkbox and switch
• Input elements often cover large areas of an application, meaning a hover would produce visual distraction when the user just moves the pointer around in the interface
• Furthermore, hover (especially hover border) often comes in conflict and confusion with the many states an input already have (focus, invalid, checked, etc.)
• Hovering the label of an input, will automatically ad hover-style for the input itself (this is natively done by the browser), but if the label and input have some distance between them, this means the user will have hover-flickering when moving the cursor between label and input
• Our input components already have a complex range of component tokens, and removing hover will simplify the component structure quite a lot - making it easier for our consumers to adjust colors to match their needs.
• Examples of design systems that does not provide input-hover: GOV.uk, Radix, IBM, [Det Fælles Designsystem](https://designsystem.dk/komponenter/tjekboks/, Salesforce, Bootstrap, Adobe Spectrum, Microsoft Fluent 2, Github Primer

Skip changing border-width on invalid:

• Changing the border-width on invalid components requires combining border+box-shadow, as changing the border width will actually change the size of the input, which might cause unwanted layout changes.
• Combining border+box-shadow only on invalid creates a more complex component token structure, and does also generate some rendering issues as both border and box-shadow receive the same border-radius and thus causing some half-pixel glitches in the edges
• Adding box-shadow to the input comes in conflict with focus-styling, meaning increased invalid border will not render when element is focsed
• Increasing border on invalid causes inconsistent input behavior, as only text inputs can get the increased border-width on invalid anyway, as our toggle inputs (checkbox/radio/switch) already have 2px border
• The change of border-color and even border-width is not sufficient indication that the input is invalid accessibility wise anyway, meaning all invalid inputs must always be accompanied by a ValidationMessage. This element will in other words be the most prominent visual indication that a input is invalid - not the change of border-width

Switch colors?

• Today, switch is the only form element that renders same background color as border color.
• This creates inconsistency in the design logic, and thus also creates the need for more component tokens than if the switch had a white background with border-colored knob/circle matching the color logic of checkbox/text/radio.
• Just suggestion - would it be an alternative to style checkbox like Microsoft does? See example below:

Switch height?

• Switch is the only input element of 28px height, aligning it to the size of radio/checkbox would simplify token structure and make it align next to checkbox radio.

Size today:	Using same scaling as checkbox/radio:

Switch readonly:

• The color of the checkmark should be same as background in readonly switch. Using background as color (used to draw the checkmark) is not possible as background accepts more advanced values such as url to images and linerar-gradient etc, whereas border-color/color on the other hand only supports plain solid colors such as #000.
• Therefore re-using background for, switch checkmark is hard. Suggestion: could the checkmark re-use border-color instead of background? This results in less contrast, but the contrast might be changed anyway in relation to Input readonly does not meet contrast requirements #2604

[mrosvik]

We have decided to follow standard behavior for input elements in V1. We will allow the discussion to continue to see if we gain further insights into which types of users might find hover either a disadvantage or an advantage, and if it does benefit some users, what they consider a good hover state for input elements.

Discussion: #2632

[mimarz]

We decided on daily today to also skip changing border-width on invalid ✅

[eirikbacker]

Closing this as switch questions is moved to #2664