-
Notifications
You must be signed in to change notification settings - Fork 24
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
legacy grapheme clusters vs extended grapheme clusters #1
Comments
Good points, Florian. I'll look at adding that information. We usually recommend extended grapheme clusters only. |
That's typically been what I've guessed should be the correct answer, but without really knowing why. And this specification looks like a great place to enlighten people in my situation. |
Is this addressed by the introduction to section 4? |
There is no mention of legacy grapheme clusters in specdev at the moment and I think this paragraph in
IMHO this kind of detail should be mentioned by charmod, not in specdev. |
"Grapheme cluster" is often the appropriate way to define "character" in a specifications (such as CSS) which care about things readers visually identify as a character.
Maybe the spec should point that out, with a link to the relevant part of unicode (http://unicode.org/reports/tr29/ I presume). There is already a mention of that in the "Indexing strings" section, but not in the "Choosing a definition of 'character'" section, where it would be particularly relevant.
Also, providing a specific definition requires picking between "legacy grapheme clusters" and "extended grapheme clusters", and I am not sure how to do that. Guidance on this topic would be appreciated.
The text was updated successfully, but these errors were encountered: