- From: Myles C. Maxfield via GitHub <sysbot+gh@w3.org>
- Date: Thu, 01 Nov 2018 16:25:41 +0000
- To: public-svg-issues@w3.org
1. Humans, in general, don't understand code points. Even programmers don't generally understand code points. Unicode [describes](https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries) grapheme clusters as "user-perceived characters" which is what someone would actually want when they tell the computer to place a thing. 2. Performing Unicode normalization should not result in different behavior. An implementation detail of the author's particular keyboard shouldn't move text around. There needs to be no visual distinction between é and e + combining acute accent. They are equivalent. 3. Code points are associated with Unicode's encoding, but user-perceived characters are, conceptually, not. A significant amount of the web is authored in non-unicode encodings, and they may not even know how their text maps to Unicode. They will know how user-perceived characters work, because they are a user and they perceive characters. 4. Fonts describe shaping rules about how to place code points (represented as glyphs that correspond to code points). A font describes, for example, how to place the combining vowel marks in Arabic, and how to assemble each of the family members in an emoji like 👨👩👧👦. Each font places them differently, and having the SVG content place these combining marks would make these kinds of texts unreadable if a new font is used (or would break up a family?). 5. If grapheme cluster boundaries change drastically, we have bigger problems than just the `x=` attribute in SVG content. Indeed, when Unicode wanted to make a change to grapheme cluster boundaries, they didn't change the old behavior, they just [added](https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries) a new type of grapheme cluster - "legacy grapheme clusters" and "extended grapheme clusters." 6. Do we have use counters for more than one entry in these position attributes? If the argument is about compatibility, we need to know how much content there is that could possibly be broken. 7. I do understand the argument about forward compatibility, but I can't differentiate the idea of "ECGs might be corrected in the future" from any other progressive behavior change we make in browsers. In general, causing a behavior change via improvements to the browser is a good thing. -- GitHub Notification of comment by litherum Please view or discuss this issue at https://github.com/w3c/svgwg/issues/537#issuecomment-435098091 using your GitHub account
Received on Thursday, 1 November 2018 16:25:43 UTC