64 characters? ▶ CSS allows all non-ASCII 😑


The body classes include:

id-1129 
_64-characters--css-allows-all-non-ascii- 
_64-characters-▶-css-allows-all-non-ascii-😑

In the child theme style.css, the related rule is:

._64-characters-▶-css-allows-all-non-ascii-😑 h1 {
	text-transform: uppercase;
	color: green;
}

But when AMP is on, it does not work.

See a non-AMP version of this page.

It works on AMP when using the also available plain ASCII class name _64-characters--css-allows-all-non-ascii-:

._64-characters--css-allows-all-non-ascii- h1 {
    text-transform: uppercase;
    color: green;
}

Now the question is: Why shouldn’t we use just that?

Consider Non-Latin script users. They should be able, too, to use the slug as a body class on a blog written entirely in Greek, or in Cyrillic, or in another among the 161 scripts out there and supported by Unicode to date (2022, v15 of the Standard).

Here, a test page with a title in simplified Greek using a transliterated Latin acronym has this URL: https://anrghg.sunsite.fr/test-amp-compat/χαιρε-εν-αμπ/

Among the three added body classes, the first one is in simplified post ID format, the second one is plain ASCII after applying default sanitization, and the third one is in Greek:

id-1164 -- χαιρε-εν-αμπ

It matches the page slug as copy-pasted from the URL bar after selecting from the last slash to the second-last.

/χαιρε-εν-αμπ/
Welcome to AMP!

This page is linked from https://anrghg.sunsite.fr/publishing-toolkit/features/helpers/#127-example-page-for-extended

Thank you for reading!
Last updated:
Published: