2 ms·

Thanks for trying to be helpful. Of course, I over-simplified our 4 years of development and the specialized field we are in. There isn't really a database invo

by a1371 5y ago

Thanks for trying to be helpful. Of course, I over-simplified our 4 years of development and the specialized field we are in. There isn't really a database involved here. I am sure there are many more correct ways for us to do certain things, that said, I respectfully disagree and macOS is the issue here. When you can be compatible with everything else, please try to be. MacOS isn't in this case. I would rather stand on the shoulder of giants who spare my staff from having to learn about "NFKC" and "NFKD". It's nicer to spend that time with our families. That's my humble opinion and personal values of course.

lilyball 5y ago
> When you can be compatible with everything else, please try to be. MacOS isn't in this case. You say that like macOS is bucking the trend. NFC is a very common normalization form for text input, regardless of whether the browser chooses to normalize. And older versions of the W3C "Character Model for the World Wide Web: String Matching" note[1] even recommended using NFC explicitly, although the current version says that skipping Unicode normalization is the recommended form of matching for "new specifications". As for Safari, it's been doing NFC normalization ever since 2006[2], and it sounds like this was originally at least partially-motivated by fixing a compatibility issue with Windows. In any case, Safari converting text to NFC is certainly differing behavior from non-WebKit browsers, but if you give someone text in NFD and they delete and retype it, it's likely to end up in NFC anyway, which means this is a problem regardless of browser. [1] https://www.w3.org/TR/charmod-norm/ https://www.w3.org/TR/charmod-norm/ [2] https://bugs.webkit.org/show_bug.cgi?id=8769 https://bugs.webkit.org/show_bug.cgi?id=8769 > I would rather stand on the shoulder of giants who spare my staff from having to learn about "NFKC" and "NFKD". Then use Unicode-aware string comparison routines.

by a1371 5y ago

lilyball 5y ago

> When you can be compatible with everything else, please try to be. MacOS isn't in this case. You say that like macOS is bucking the trend. NFC is a very common normalization form for text input, regardless of whether the browser chooses to normalize. And older versions of the W3C "Character Model for the World Wide Web: String Matching" note[1] even recommended using NFC explicitly, although the current version says that skipping Unicode normalization is the recommended form of matching for "new specifications". As for Safari, it's been doing NFC normalization ever since 2006[2], and it sounds like this was originally at least partially-motivated by fixing a compatibility issue with Windows. In any case, Safari converting text to NFC is certainly differing behavior from non-WebKit browsers, but if you give someone text in NFD and they delete and retype it, it's likely to end up in NFC anyway, which means this is a problem regardless of browser. [1] https://www.w3.org/TR/charmod-norm/ https://www.w3.org/TR/charmod-norm/ [2] https://bugs.webkit.org/show_bug.cgi?id=8769 https://bugs.webkit.org/show_bug.cgi?id=8769 > I would rather stand on the shoulder of giants who spare my staff from having to learn about "NFKC" and "NFKD". Then use Unicode-aware string comparison routines.