Csswg-drafts: [css-text] Provide CSS support for automatic spacing (or other separators) in text input field

[marvindanig]

This is a feature request to allow styling of the text input field for formatted inputs like credit card or date or phone number with an area code. Currently this is not possible without using javascript.

Shown below is an example where a credit card number is split into groupings of four digits each:

In general, people tend to use comma separation or spaces between large numbers (like a credit card) to pin for accuracy of input. So in some ways this is an accessibility issue as well.

At this point all of the solutions out there require using javascript to format the inputted string by listening to the onblur event. There are even libraries from large providers to style the information fields such as this one from Stripe. Linked here is the Twitter thread that prompted this proposal.

[AmeliaBR]

I agree that this is a common design need. I don't have references right now, but I remember reading somewhere that editing the input on blur (to add hard-coded spaces or other separators) can be an accessibility issue.

My rough strawman proposal (from the Twitter thread) was that spacing could be supported by extending the letter-spacing property to support a sequence of spaces, like 0 0 0 1ch for a space after every fourth character.

But that wouldn't help with things like automatically adding dashes to phone numbers or automatically formatting numbers with commas, so maybe a more dedicated number-format approach would be better.

I still think it's useful to talk about this in CSS (as opposed to something like a format attribute on an HTML <input>), so that the same approach works for custom inputs or general number formatting (e.g., in a data table).

[Loirooriol]

Something like a custom text-transform that replaces every 4th character with itself and a space or dash? The spec already says

A future level of CSS may introduce the ability to create custom mapping tables for less common text transforms, such as by an @text-transform rule similar to @counter-style

[Crissov]

This be #3132 then.

With @frivoalʼs proposal, authors could change the separators and grouping characters, but they could not add them at arbitrary places or intervals.

[tabatkins]

Yeah, I agree that this is a pretty common and reasonable thing to want. Scoping the design will be interesting, but I suspect it's doable.

[plinss]

Note that not all credit cards use a 4/4/4/4 format. Other common formats are 4/4/4, 4/4/5, 4/4/4/2, 4/6/5, 6/11, 6/12, 6/13, and 4/4/4/3. A proper credit card input implementation will look at the card digits to determine the issuer and switch formats as the user is typing. Similar issue for phone numbers. Whatever we do here has to be dynamic, at the least letting the author change formats in a non-destructive manner in response to input events.

[AmeliaBR]

@plinss That's a good point. But considering that all existing implementations use dynamic JS anyway, it might still be an improvement if they could preserve the distinction between the input characters and the formatting adjustments.

[plinss]

I’m not saying that odd cases like credit cards and phone numbers should be doable without JS entirely, a small amount of code in an oninput to swap formats is fine, and IMO desirable because there’s no way we can predict all the ways this will be used. Just that an author should be able to swap the formatter dynamically without interfering with user input.

I wrote a CC input that does the dynamic formatting by adjusting the value, and it was a PITA and still likely misbehaves in some circumstances. I’d love to be able to throw that away for something that works gracefully.

[tabatkins]

Ah yup, a script that just adjusts input.style.formatPattern on the fly would be big improvement over that.

[ByteEater-pl]

Per the principle of least power, could regular expressions be a viable alternative to scripting? (Events could be fired anyway in case the author wants to do something more than declaratively possible, as with animations and much other CSS stuff.)

[fantasai]

I think this request makes a lot of sense, but I think it probably belongs at the HTML layer. @ByteEater-pl’s suggestion to use regex makes sense: we already have a pattern attribute to validate input, maybe a format attribute that, using captured substrings, describes the output formatting?

[ByteEater-pl]

While validation is indeed a host language concern, displaying transformed text seems more like a generalization of text-transform and applicable regardless of if it's HTML being styled or something else.

[faceless2]

This seems to be another variation of "I need to apply a transform to text styled with CSS to modify spacing, or change it in a way more complex than what we can currently do with text-transform".

It's a problem that keeps coming up. it's been solved so many times and in so many ways, it seems odd that a more generalised "text-fixup" option isn't part of CSS. Here's my partial list of references.

https://www.w3.org/TR/css-text-4/#text-spacing-property
https://www.w3.org/Style/2013/paged-media-tasks#text-fix
https://www.princexml.com/doc/css-props/#prop-prince-text-replace
https://www.antennahouse.com/product/ahf66/ahf-ext.html#axf.text-replace
https://specs.rivoal.net/css-custom-tt/
https://books.idea.whatwg.org/#character-substitution

4246

All of these proposals relate primarily* to changing the _formatted_ value of the text, rather than the _logical_ value: this proposal included (I don't think there request is that spaces are included as part of the submitted credit card number, just that they're included when the value is displayed on screen).

For this reason I think it's a styling issue and part of CSS's domain.

(*) this is a slightly blurred distinction - first because although that seems to be how it's normally used, it doesn't have to be (see for example https://lists.w3.org/Archives/Public/www-style/2008Sep/0013.html), and second because of https://github.com/w3c/csswg-drafts/issues/3775

[AmeliaBR]

I am currently filling out a PDF form & I noticed that after I edit, it is automatically formatting the numbers with commas for thousands separators. Here are Adobe docs for the types of formats that are supported:
https://helpx.adobe.com/ca/acrobat/using/pdf-form-field-properties.html#format_tab_for_form_field_properties

Might be worth further investigation to see if that model could be adapted in a consistent yet CSS-compatible way.

[faceless2]

In PDF that's all done with JavaScript.

PDF has "keypress" events which fire as you type into the field, and a "format" event which fires when the value of the field changes. It also makes a distinction between the actual value of the field and the _formatted_ value as it appears on screen - the two can be different, which is how you can get commas in the values you see on screen, but not in the submitted value.