Prefixes and suffixes for textual <input>
s
#10314
Labels
addition/proposal
New features or enhancements
needs implementer interest
Moving the issue forward requires implementers to express interest
topic: forms
What problem are you trying to solve?
Many textual
<input>
use cases require a static prefix or suffix that cannot be edited:In some cases, the intent is for it to be part of the value, mainly around constraining the input (tighter feedback loop than relying on form validation), communicating the expected value, and saving the user effort:
<input type="url">
:https://
)https://twitter.com/
"<input type="email">
:@companyname.com
)In other cases, the intent is that the prefix/suffix wouldn’t be part of the value. I cannot think of cases beyond
<input type="number">
where we want the value to still be a parse-able number, but these are not a small set (and in fact are the motivating use cases for this proposal):<input type="number">
€
)%
)cm
)What solutions exist today?
::before
and::after
are not available.How would you solve it?
I can see two solutions which are independent, but complementary:
prefix
andsuffix
attributes which affect the actual value returned by thevalue
IDL attribute, are communicated to assistive tech accordingly, and are taken into account during form validation. For non-textual inputs, perhaps they could still affect the value returned, but there is no UI to show this.<input>
, which would be perfect for presentational prefixes and suffixes. This actually seems like a perfect example of something for the new CSS WG - WHATWG task force.Anything else?
Ideally use cases like measurements or currencies deserve their own input, but something like this solves the immediate pain point and requires much less design & implementation effort than speccing a whole new control (which doesn't even satisfy all use cases).
An alternative design specifically for
<input type=number>
and<input type=date>
(and other temporal inputs) could be aformat
attribute that takes parameters analogous to those ofIntl.NumberFormat
/Intl.DateTimeFormat
. While that would be narrower in terms of input types, it would be broader in the sense that not all formatting pain points are solved by adding prefixes and suffixes (if only I had a dollar for how many times I’ve seen users enter thousand separators into<input type=number>
…). If that's of interest, I could flesh the design out more in a separate proposal, but since it would be considerable effort, I wanted some indication of interest first.The text was updated successfully, but these errors were encountered: