Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefixes and suffixes for textual <input>s #10314

Open
LeaVerou opened this issue May 1, 2024 · 0 comments
Open

Prefixes and suffixes for textual <input>s #10314

LeaVerou opened this issue May 1, 2024 · 0 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: forms

Comments

@LeaVerou
Copy link

LeaVerou commented May 1, 2024

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">:
    • Pre-filling the protocol (e.g. https:// )
    • Pre-filling a specific URL (e.g. "Your Twitter account: https://twitter.com/ "
  • <input type="email">:
    • Pre-filling the domain (e.g. "Your work 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">
    • Currency (e.g. )
    • Percentage (e.g. %)
    • Unit (e.g. cm)

What solutions exist today?

  • Since inputs are considered replaced elements, ::before and ::after are not available.
  • Probably the most common solution is to wrap the input with a wrapper that includes the prefix/suffix (either via generated content or actual text), and painfully style the wrapper to look like an input, then handle the joining in code, if the prefix/suffix are desired to be included in the value.
  • I’m sure we've also all seen fragile attempts to implement this via intercepting keyboard events in the wild, and experienced how painful that UX is.
  • I have at some point used the horrible hack of generating an SVG background image that contained the text I wanted. 😅 I’m not proud of this, but without getting into too much detail, that was a highly constrained use case, where the solutions above were not tenable.

How would you solve it?

I can see two solutions which are independent, but complementary:

  1. prefix and suffix attributes which affect the actual value returned by the value 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.
  2. Allowing CSS generated content on textual <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 a format attribute that takes parameters analogous to those of Intl.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.

@LeaVerou LeaVerou added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest topic: forms
Development

No branches or pull requests

3 participants
@LeaVerou @annevk and others