Open Febakke opened 1 week ago
Investigate: Should we have hover state on input components?
Simplifications for our input components:
Skip using hover:
Skip changing border-width on invalid:
border
+box-shadow
, as changing the border width will actually change the size of the input, which might cause unwanted layout changes.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 edgesbox-shadow
to the input comes in conflict with focus-styling, meaning increased invalid border will not render when element is focsed2px
borderValidationMessage
. This element will in other words be the most prominent visual indication that a input is invalid - not the change of border-widthSwitch colors?
Switch height?
Size today: | Using same scaling as checkbox/radio: |
---|---|
Switch readonly:
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
.border-color
instead of background
? This results in less contrast, but the contrast might be changed anyway in relation to #2604
All
inputs
will soon be one component with different types in code. For examppleinput 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?