[css-text] Custom character replacement rules for text-transform

[Crissov]

There is a 2011 (and subsequently updated) proposal by @frivoal for Defining Custom Text Transforms which I don't see being tracked on Github yet.

@text-transform <transform-name> { [ descriptor: value; ]+ }

Descriptors

Name	Value	Default
transformation	<conversion>#	N/A
character-type	extended | legacy | single | spaced	extended
scope	all | [initial || medial || final]	all

<conversion> = [<char-list> to <char-list>] | <'text-transform'>
<char-list> = <enumeration> | <range>
<range> = <urange> | <string>
<enumeration> = <string>

[frivoal]

I've moved this proposal from the wiki to my site a while back:
https://specs.rivoal.net/css-custom-tt/

I still think it'd be an interesting thing to pursue, but I have hardly heard anything back about this in the 6 years it's been out, so I'm not convinced interest is high enough.

[upsuper]

One suggestion, let's not continue using the plain <custom-ident>. I think it was probably a mistake to allow arbitrary identifier to be used like keyword values, for several reasons:

1. invalid value can suddenly become valid which leads to unexpected behavior change for some error cases,
2. it restricts our future extension to the property,
3. make implementation more complicated (for example, @counter-style requires names in a given list to be case-insensitive, which wouldn't be necessary if we don't allow overriding from the very beginning).

Maybe either require prefixing custom values with -- or use string instead.

(I probably should update Gecko's @counter-style implementation so that we can get rid of these pitfalls from there as well... I guess it is doable...)

[SebastianZ]

@frivoal The character-type descriptor is missing a description in your draft spec. What are its values meant for?

Sebastian

[SebastianZ]

#4875 mentions the use case to insert characters at specific positions. I think the proposed @text-transform rule should also cover that case and other transformations that go beyond character replacements.

So far, credit card and phone numbers were mentioned in the other issue. I can imagine formatting other types of numbers like currencies might be a thing, as well. Specifically, adding thousands separators and changing the floating point based on the locale could be something that's covered by that at-rule.
Other use cases might be string replacements like in the references mentioned earlier by @faceless2.

Though the more complex the transformations are, the higher the impact is on the performance, of course.

Sebastian

[frivoal]

The character-type descriptor is missing a description in your draft spec.

Sorry that was dropped a while back, and there was some stray text still referring to it. This is now gone, you can ignore it.