CSS Custom Text transformations

1. Introduction

1.1. Motivating scenarios

2. Module Interactions

3. Defining Custom Text transformations: the @text-transform rule

The general form @text-transform rule is:

@text-transform <transform-name> {
  <declaration-list>
}
<transform-name> = <custom-ident>

The @text-transform rule accepts the following descriptors: transform and position. The transform descriptor is required, and the @text-transform rule has no effect if it is omitted. Other descriptors may be omitted, and evaluate to their initial value in that case. When a given descriptor occurs multiple times in a given @text-transform rule, only the last one is used; all prior instances of that descriptor within that rule must be ignored.

These descriptors apply solely within the context of the enclosing ''@text-transform, and do not apply to document elements.

define what happens when multiple Custom Text transformations by the same name are declared.

The text-transform property is extended by this specification to accept Customer Text transformations, refered to by their <transform-name>, as values:

With the exception of CSS-wide keywords which always have their global meaning, if <transform-name> conflicts with an existing value of the text-transform property, the conflict is resolved in favor of the custom definition introduced using @text-transform.

Note: This enables the addition by later specifications of new keywords for the text-transform property without changing the behavior of any existing page already defining and using a custom text transformation by the same name.

3.1. Defining the transformation: transform descriptor

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

This descriptor defines which character will be replaced by which, by listing a series of conversions, to be applied in the same order as they appear in the descriptor.

Conversions may refer to existing text transformations, either predefined by CSS or defined by the author.

Note: While a transformation using only a single such conversion is not very useful, combining it with other conversions allows authors to extend or define variants of existing transformations.

Referring to the text-transform currently being defined is not allowed, and makes the whole descriptor invalid.

Conversions may also define new mapping from one <char-list> to another. When defined using a <urange>, the <char-list> is is an ordered list of each individual Unicode character code point designated by the <urange>.

A <range> may also be defined as a string made of a single unicode character, followed by a hyphen (U+002D), followed by another signle unicode character. The semantics are identical to the <urange> U+XXXXXX-YYYYYY where XXXXXX is the code point of the first character and YYYYYY the code point of the second character. Any other string is interpreted as an <enumeration>.

Note: This notation is included despite being redundant with the <urange> notation as is is much more readable in many situations.

Since these operate on single code points, which normalization (if any) is used matters. Should we have a way to switch how they apply? Should we have built-in nfc, nfd, nfkc and nfkd transforms?

If defined by an <enumeration>, the <char-list> is an ordered list of each extended combining character squence in the string, The same character may not appear twice in the <char-list> defining the source of the mapping, otherwise the whole descriptor is invalid.

Note: In addition to the usual CSS rules of character escaping, hyphen (U+002D) need to be escaped to appear in second position of a 3 charater long <enumeration>. The string would otherwise be interpreted as a <range>.

This ability to have both enumeration strings and range strings is nice for authors, but is this something implementors are willing to live with, or does it make parsing too cumbersome? Wrapping the strings in functional notation would solve the problem, at the expense of making the syntax much more verbose and less readable.

In a <conversion>, if the source <char-list> is longer than the target <char-list>, then the last item of the target list is used for all remaining items in the source list.

Note: This allows shortcuts like transform: "aàáå" to "a".

We probably need a switch of some kind to be able to operate only on base characters. Maybe also only on combining marks, or sets of combining marks. At least for base characters only, there are clear use cases.

Should we allow spaces and other collapsible characters in the target? Since text-transform is applied after white space collapsing, what are the implications of generating runs of collapsible white space that won’t be collapsed? It has been proposed that we should allow them, and trigger a second white space collapsing if they are actually used.

Should we allow an empty <char-list> as the target? It has been suggested that this be used to delete text. I am not sure I like the idea that text-transform could be able to make some non-empty element empty.

It has been suggested that it should be possible to write text-transforms that behave differently on different languages. This can probably be achieved by adding some optional part at the beginning of each <conversion>, although I am not sure what the syntax should be.

@text-transform latin-only-uppercase {
  transform: "a-z" to "A-Z";
}

@text-tranform abcdef1 {
  transform: "abc" to "def";
}
@text-tranform abcdef2 {
  transform: "a" to "d",
             "b" to "e",
             "c" to "f";
}

3.2. What the transformation applies to: the position descriptor

This descriptor makes it possible to restrict which characters in the source text are affected by the transform.

• all lets the transformation apply to any character
• initial lets the transformation apply at the beginning of a word
• medial lets the transformation apply to characters within a word other than at the beginning and the end.
• final lets the transformation apply at the end of a word

The definition of word is UA-dependent; [UAX29] is suggested (but not required) for determining such word boundaries.

The transform descriptor may be used to refer to existing text-transforms in the definition of a new one. If the text-transforms referred to has a different position than the position specified in the text-transform that refers to them, they apply at the intersection of the two positions.

@text-transform latin-only-uppercase {
  transform: "a-z" to "A-Z";
}
@text-transform latin-only-capitalize {
  transform: latin-only-uppercase;
  position: initial;
}

4. DOM interaction

Custom text transformation values defined within @text-transform rules are accessible via the following modifications to the CSS Object Model.

partial interface CSSRule {
  const unsigned short TEXT_TRANSFORM_RULE = 1000;
};
interface CSSTextTransformRule : CSSRule {
  attribute          DOMString   name;
  readonly attribute CSSStyleDeclaration  style;
};

This is a lousy OM. Do better.

Apendix A. Use cases and Examples

Single-Language uses

The following use cases only apply to a single language. Defining all the possibly useful text-transforms for all languages would go beyond the capacity and expertise of the CSS WG. Having the generic mechanism allows authors to solve their specific problem.

@text-transform full-size-kana {
  transform: "ぁぃぅぇぉゕゖっゃゅょゎ" to "あいうえおかけつやゆよわ",
             "ァィゥェォヵㇰヶㇱㇲッㇳㇴㇵㇶㇷㇸㇹㇺャュョㇻㇼㇽㇾㇿヮ" to "アイウエオカクケシスツトヌハヒフヘホムヤユヨラリルレロワ",
             "ｧｨｩｪｫｯｬｭｮ" to "ｱｲｳｴｵﾂﾔﾕﾖ";
}

@text-transform german-uppercase {
  transform: U+00DF to U+1E9E, uppercase;
}

@text-transform german-lowercase {
  transform: U+1E9E to U+00DF, lowercase;
}

@text-transform uppercase {
  transform: U+00DF to U+1E9E;
  language: de;
}

@text-transform uppercase:lang(de) {
  transform: U+00DF to U+1E9E;
}

@text-transform turkic-uppercase {
  transform: "i" to "İ", uppercase;
}

@text-transform turkic-lowercase {
  transform: "I" to "ı", lowercase;
}

@text-transform Mkhedruli-to-Asomtavruli {
  transform: "ა-ჵ" to "Ⴀ-Ⴥ";
}

@text-transform Asomtavruli-to-Mkhedruli {
  transform: "Ⴀ-Ⴥ" to "ა-ჵ";
}

@text-transform georgian-uppercase {
  transform: Mkhedruli-to-Asomtavruli;
}
@text-transform georgian-capitalize {
  transform: Mkhedruli-to-Asomtavruli;
  position: initial;
}
@text-transform georgian-lowercase {
  transform: Asomtavruli-to-Mkhedruli;
}

Cross-language uses

@text-transform modernize-s {
  transform: "ſ" to "s";
}

@text-transform long-s {
  transform: "s" to "ſ" ;
  position: initial medial;
}

Miscellaneous

@text-transform fake-norse {
  transform: "aoAO" to "åøÅØ";
}

@text-transform leet-speak {
  transform: "A-Z" to "48©)3F6H1!K£MN0¶9®57UVW*¥2";
}

@text-transform rot13 {
  transform: "A-M" to "N-Z", "N-Z" to "A-M",
             "a-m" to "n-z", "n-z" to "a-m";
}
.spoiler:hover {
    text-transform: rot13;
}

<p class="spoiler">Qnegu Inqbe vf Yhxr’f sngure.</p>

Apendix B. Security and Privacy Considerations

This appendix is non-normative.

There are no known security or privacy impacts of this feature.

The W3C TAG is developing a Self-Review Questionnaire: Security and Privacy for editors of specifications to informatively answer. As far as currently known, here are the answers to the Questions to Consider:

Does this specification deal with personally-identifiable information?

No

Does this specification deal with high-value data?

No

Does this specification introduce new state for an origin that persists across browsing sessions?

no

Does this specification expose any other data to an origin that it doesn’t currently have access to?

No

Does this specification enable new script execution/loading mechanisms?

No

Does this specification allow an origin access to a user’s location?

No

Does this specification allow an origin access to sensors on a user’s device?

No

Does this specification allow an origin access to aspects of a user’s local computing environment?

No

Does this specification allow an origin access to other devices?

No

Does this specification allow an origin some measure of control over a user agent’s native UI?

No. However, it does allow changes to the text displayed in some “native-looking” form controls and replaced elements within the page. As these are under author control anyway, this is not considered a risk.

Does this specification expose temporary identifiers to the web?

No

Does this specification distinguish between behavior in first-party and third-party contexts?

No

How should this specification work in the context of a user agent’s "incognito" mode?

No difference in behavior is expected or needed.

Does this specification persist data to a user’s local device?

No

Does this specification have a "Security Considerations" and "Privacy Considerations" section?

Yes, this is the role of this Appendix.

Does this specification allow downgrading default security characteristics?

No