Text input component #30
jare2473
ansv7779
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "text_input"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Addresses issue #17
Note: TheSans is a commercial font I don't have access to.
Can be viewed on:
https://studentportalen-textinput.branch.dsv.su.se/
Perfect! The input text color did not feel right to me (not enough contrast to the placeholder), so I looked at the SU website and saw that they are using black (#FFFFFF) in (some) text input fields.
So I say, let us also "break the rules" of the SU graphic profile and add this to the color palette. I have updated the text input overview and the color overview in figma.
In short, change the text input color from Base/Ink/Strong to Base/Ink/Max.
@ -0,0 +4,4 @@/*** Icon sizes matching the design system control sizes.*/export type IconSize = "sm" | "md" | "lg";Shouldn't icons inherit their size from their context? Like if I add an icon to a small button or a large heading I would assume it would scale to that context rather than having its own independent size.
For certain cases, yes, it probably should. I've added inherit as a default. However, we need to be able to override it like in the TextInput component. Here, the icon is in a dedicated container that's sized by --control-height-* tokens, not font-size. There's no text for it to "inherit" from since the icon container and the input text are siblings, not parent/child.
@ -0,0 +8,4 @@export interface TextInputPropsextends Omit<InputHTMLAttributes<HTMLInputElement>, "size"> {size?: TextInputSize;Icon?: IconComponent;Iconwith capitalI?Yes, it's a component
@ -0,0 +9,4 @@extends Omit<InputHTMLAttributes<HTMLInputElement>, "size"> {size?: TextInputSize;Icon?: IconComponent;error?: boolean;Without having seen an example of a full form with validation it's hard to tell if this is the path forward. We can probably leave it for now.
I am wondering about using built-in form validation and the
:validand related pseudo-selectors and how it works with accessibility without it.I’d keep the error prop for now. Native validation works for some cases but gets awkward once you have server errors or custom validation. An explicit error state keeps the component predictable.
@ -0,0 +12,4 @@error?: boolean;fullWidth?: boolean;customWidth?: string;label?: string;Should label really be optional? Will that not lead to accessibility issues?
In practical implementation, probably not, that was how the component was designed in the specification.